Is your feature request related to a problem? Please describe.

The OpenTelemetry Java JDBC instrumentation does not recognize the URL scheme registered by AWS's Aurora DSQL JDBC Connector (software.amazon.dsql:aurora-dsql-jdbc-connector). When the connector is on the classpath it self-registers as jdbc:aws-dsql:postgresql://, e.g.:

jdbc:aws-dsql:postgresql://<cluster-id>.dsql-<family>.<region>.on.aws:5432/postgres

JdbcConnectionUrlParser reads the substring between jdbc: and the first : as the "type" key, gets aws-dsql, finds no entry in typeParsers, and routes to GenericUrlParser.INSTANCE. Generic parsing extracts a best-effort host but does not understand the trailing /postgres as the database name, so the resulting DbInfo ends up without db.name populated and db.system not set to postgresql.

The concrete user-visible effect is that JDBC span names lose their database prefix. For example, after a service switches from the stock org.postgresql:postgresql driver (URL jdbc:postgresql://…) to the DSQL Connector (URL jdbc:aws-dsql:postgresql://…) on the same database, span names change from:

INSERT postgres.my_table       (before)
INSERT my_table                (after)

Any dashboard, alert, or sampling rule keyed on JDBC span names with a <database>.<table> shape silently goes empty once a service adopts the connector. Dashboards must either be rewritten to drop the <database>. prefix or carry a DSQL-specific regex branch.

The DSQL Connector is the AWS-recommended path for connecting Java applications to Aurora DSQL (docs (https://docs.aws.amazon.com/aurora-dsql/latest/userguide/SECTION_program-with-jdbc-connector.html)) because it handles IAM token signing, SSL configuration, and ApplicationName. Services that need DSQL effectively must use it.

Describe the solution you'd like

Add jdbc:aws-dsql: as a recognized wrapper prefix in JdbcConnectionUrlParser.stripJdbcPrefix (source (https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jdbc/library/src/main/java/io/opentelemetry/instrumentation/jdbc/internal/JdbcConnectionUrlParser.java)). The connector's URL after the aws-dsql: segment is a standard PostgreSQL JDBC URL, so the fix can delegate to the existing PostgresqlUrlParser rather than duplicate its logic. This mirrors the precedent set by jdbc:tracing: (opentracing-contrib) and jdbc-secretsmanager: (AWS Secrets Manager JDBC), both of which stripJdbcPrefix already handles by peeling a wrapper layer.

Sketch:

private static String stripJdbcPrefix(String connectionUrl) {
  if (connectionUrl.startsWith("jdbc:tracing:")) {
    return connectionUrl.substring("jdbc:tracing:".length());
  } else if (connectionUrl.startsWith("jdbc:aws-dsql:")) {
    // AWS Aurora DSQL JDBC Connector wraps a postgresql URL.
    return connectionUrl.substring("jdbc:aws-dsql:".length());
  } else if (connectionUrl.startsWith("jdbc:")) {
    return connectionUrl.substring("jdbc:".length());
  } // ... existing secretsmanager branches
}

With that change in place, parsing the URL above would produce:

• server.address = .dsql-..on.aws
• server.port = 5432
• db.name = postgres

A unit test mirroring the existing parsePostgres* cases in the same package should cover it.

Open question for maintainers — db.system value. Two reasonable choices:

1. postgresql — what falls out naturally if stripJdbcPrefix delegates to the postgresql case. Maximally backward-compatible: existing dashboards / alerts that filter on db.system=postgresql will pick up DSQL traffic without change. Matches OTel's existing treatment of CockroachDB (also wire-compatible with Postgres, reported as postgresql).
2. aws.dsql (or similar) — mints a new value so users can distinguish DSQL traffic from stock Postgres in PromQL/LogQL. Matches OTel's treatment of MariaDB (wire-compatible with MySQL but reported separately). Costs back-compat for any consumer already filtering on db.system=postgresql.

Happy to follow whichever the maintainers prefer — leaning toward aws.dsql, but the call is yours.

Describe alternatives you've considered

• Custom JDBC URL parser per-service. Each adopter could register a JdbcUrlParser for aws-dsql themselves, but the parser registry (JdbcConnectionUrlParser#typeParsers) is package-private and internal, so this isn't a supported extension point today.
• OTEL attribute processor to rewrite db.name. Works post-hoc but requires every adopter to deploy collector-side or SDK-side processors with knowledge of DSQL's URL shape — duplicative.
• Dashboard-side workaround. Drop the <database>. prefix from span_name regexes (what we've done locally). Acceptable as a stopgap; the cost is each consumer dashboard has to know that DSQL is the special case.

None of these scale across the OTel JDBC user base the way a one-line addition to stripJdbcPrefix would.

Additional context

• AWS Aurora DSQL JDBC Connector: software.amazon.dsql:aurora-dsql-jdbc-connector (https://docs.aws.amazon.com/aurora-dsql/latest/userguide/SECTION_program-with-jdbc-connector.html). The connector is the AWS-blessed path for IAM-authenticated DSQL connections from Java and is on the GA track.
• DSQL's database segment is always literally postgres — Aurora DSQL does not support user-named databases.
• Empirically verified on the Java Agent (current release at time of filing) that span names change from postgres. to when a service switches from jdbc:postgresql://… to jdbc:aws-dsql:postgresql://… against the same database.

  Tip

  _{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}