Application monitoring can tell you when a performance problem leads back to the database. It won't tell you which of the hundreds of queries running against it is worth your attention, or what to change once you've found it. Unless someone on your team owns database performance full-time, that search becomes a bottleneck.
AI could close that gap, but only if you can trust the answer. An LLM can suggest an optimization, but plausible isn't proven, and plausible often isn't enough to justify changing a production database. The real challenge is proving a recommendation will improve performance before you act on it, especially when nobody on hand has deep database expertise.
We'll walk through the whole path: what a trace tells you on its own, where database-level visibility picks up, and how Datadog Bits Database Optimizations continuously detects and validates fixes before they're surfaced. Whether your team owns the database or the services that depend on it, finding what's slow and deciding what's worth fixing happens autonomously, so the database can stop being the bottleneck.
What you'll take away:
- Where application monitoring ends and database visibility begins. What a trace tells you when a query times out, and why that's the point most teams run out of recourse.
- Why optimization work stalls. Finding and prioritizing the queries worth fixing takes expertise most teams don't have available, so the work waits for an incident to justify it.
- What it takes to prove an optimization before you run it. How validating a fix against a realistic version of your own workload differs from an LLM proposing something that looks reasonable.
- How performance work keeps pace with developer velocity. What changes when the queries worth fixing surface continuously, rather than after an endpoint times out.
Why you should attend:
- The trace stops at the database. You can see that the database is at fault and still have no idea which query or why. We cover how Datadog Database Monitoring fills that gap.
- Database expertise isn’t a given. Application developers write the queries; a small platform or database team owns the consequences. We cover how findings in context are surfaced so they can act on them.
- Optimization gets deprioritized because nothing is technically broken. Slow isn't down, so it loses to the roadmap until it becomes an incident. We cover what continuous detection changes about that trade-off.
- Nobody wants to change a production database on a hunch. We cover how validating a fix against a realistic version of your workload turns a suggestion into something a reviewer can approve.
- Change volume outpaces review capacity. Developers ship faster than any team can review by hand, and AI-assisted development has increased that volume rather than reduced it. We cover how detection keeps up.
Your Speakers
Alex Weisberger Senior Software Engineer, Datadog
Alex works on the Database Monitoring team, where he helped build Bits Database Optimizations.
Sophie Bymark Product Marketing Manager, Datadog
Sophie is a Product Marketing Manager at Datadog focusing on Database Monitoring.
