Problem Statement
Description:
Currently, Sentry groups all database spans under a generic db operation regardless of whether the underlying driver is async (e.g. asyncpg) or sync (e.g. SQLAlchemy). There is no span.op, attribute, or tag that differentiates the two at the span level.
Our stack:
FastAPI (async)
asyncpg (async DB driver)
SQLAlchemy (sync ORM in some services)
Some way to distinguish async from sync DB spans — either via span.op (e.g. db.async vs db.query), a span attribute like db.driver, or at minimum a tag indicating the driver being used.
Why it matters:
In async-first stacks (FastAPI + asyncpg), mixing async and sync DB operations can have real performance implications — connection pool contention, event loop blocking, etc. Without span-level differentiation, APM traces don't give enough signal to diagnose these issues effectively.
This came up directly when evaluating Sentry against ELK for our observability stack. ELK allows custom field-level filtering that makes this distinction trivial. Closing this gap would make Sentry's APM significantly more useful for async Python backends, which are increasingly the norm.
Solution Brainstorm
No response
Product Area
Performance
Problem Statement
Description:
Currently, Sentry groups all database spans under a generic db operation regardless of whether the underlying driver is async (e.g. asyncpg) or sync (e.g. SQLAlchemy). There is no span.op, attribute, or tag that differentiates the two at the span level.
Our stack:
FastAPI (async)
asyncpg (async DB driver)
SQLAlchemy (sync ORM in some services)
Some way to distinguish async from sync DB spans — either via span.op (e.g. db.async vs db.query), a span attribute like db.driver, or at minimum a tag indicating the driver being used.
Why it matters:
In async-first stacks (FastAPI + asyncpg), mixing async and sync DB operations can have real performance implications — connection pool contention, event loop blocking, etc. Without span-level differentiation, APM traces don't give enough signal to diagnose these issues effectively.
This came up directly when evaluating Sentry against ELK for our observability stack. ELK allows custom field-level filtering that makes this distinction trivial. Closing this gap would make Sentry's APM significantly more useful for async Python backends, which are increasingly the norm.
Solution Brainstorm
No response
Product Area
Performance