The Database Assumptions AI Agents Break

Most application databases were built around two assumptions: queries come from people or ORMs developers configured, and load is bounded by human demand.

AI agents break those assumptions.

AI agents query continuously against the same infrastructure sized for human-pace traffic, with no review cycles, ticket queues, or natural ceiling. Traditional spikes are bounded: a flash sale ends, a viral moment fades, a product launch settles. Agentic workloads are persistent, and because queries are generated dynamically rather than written and reviewed, the patterns are harder to predict, optimize, and debug.

There are a few infrastructure assumptions that break down specifically under these conditions:

• Replicas: You can add replicas to handle more query volume, but a slow query does not become cheaper or faster to execute just because more replicas are available. Adding replicas distributes volume but not cost. At agent scale, the right question is whether those queries need to execute at all, high-frequency reads on stable data are caching candidates, not scaling candidates.
• Connection pooling: Connection pooling configurations were also sized for human-paced application traffic. Agents exhaust pools because they query continuously without natural pauses. Tighter scoping of what agents can access, combined with connection limits per agent context, reduces the blast radius significantly.
• Query caching: Query caching strategies assumed that engineers could predict which access patterns would become hot. Static cache warming fails when agents generate unpredictable patterns. The teams getting this right are using systems that observe live traffic and cache automatically, so the cache adapts as patterns shift rather than requiring engineers to predict them upfront.

The teams handling this well are not necessarily rebuilding their infrastructure. They are rethinking what they observe and what they automate. As agents generate more of the query load, the gap that matters is query visibility and automated performance management. Tools like RDST make it practical to catch expensive query patterns before they reach production, while QueryPilot handles caching decisions automatically by observing live traffic.

🔍 What We're Watching in the Database Ecosystem

Strengthening the MySQL Community: Highlights from Our Third Public Discussion

Oracle and the MySQL community held their third public roadmap discussion in April, focused on transparency, contributor participation, and how community input is shaping future MySQL releases. The MySQL Contributor Summit is set for May 26. Worth reading if you work with MySQL or want to get a view into Oracle's evolving community strategy.

Datadog State of AI Engineering 2026

Datadog's research this week on how AI engineering is changing in production. The finding most relevant to database teams: capacity constraints are now the dominant failure mode for AI applications, not model quality. In March 2026, rate limit errors accounted for nearly 8.4 million LLM call failures. The databases sitting underneath these systems are absorbing load they were never designed for, and most teams have not yet adjusted their infrastructure assumptions accordingly.

In Case You Missed It

How Much Are Your Read Replicas Actually Costing You?

We are hosting a live demo on May 19 at 8:00 AM PT / 11:00 AM ET. We'll run RDST against a real database fleet, break down what is driving load, and show how to surface the queries responsible for the majority of cost and latency, and fix them, directly from the CLI. Register here.

New on our Blog:

Replication Internals: Decoding the MySQL Binary Log, Part 10 - ROTATE_EVENT: Marcelo continues the binary log series with the ROTATE_EVENT, the event that signals the end of one log file and the start of the next.

Know a database aficionado who'd appreciate this? Forward it their way.