The Problem Nobody Wants to Own #
Someone on your team owns the database. It probably isn’t a job title anyone holds. It’s the engineer who set up RDS three years ago and never quite handed it off. The one who gets paged when query latency spikes at 2 AM, who notices that a migration someone ran on Friday has been holding an exclusive lock for six hours, who knows off the top of their head that max_connections is set too high, and why that’s a problem rather than a solution.
Let’s call this person Alex. Alex is fictional, but the 2 AM page is real, and so is the arrangement: database ownership dumped on top of a full plate of other responsibilities, documented nowhere but a Confluence page titled “DO NOT TOUCH (seriously)” and the contents of one engineer’s head.
The problem isn’t that database work is hard – it’s that it’s invisible until it isn’t. Optimization falls through the cracks not because people don’t care, but because there’s no natural place in the engineering org for it to live.
Today, DBO, our Database Optimizer, is generally available. It isn’t a replacement for Alex – it’s the tool that takes on the continuous, unglamorous work of database optimization, so Alex doesn’t have to carry it around as institutional knowledge. Here’s the worst week of Alex’s life, twice.
Monday, 2:07 AM: The Query That Outgrew Its Index #
PagerDuty goes off. p99 latency on the orders service has tripled overnight. Two hours of digging later, the culprit turns out to be a query doing a sequential scan across a table that grew 100x this quarter. The fix is a single missing index. Creating the index was never the hard part; the hard part was knowing which of the 4,000 queries hitting production was the one that mattered.
With DBO: the Performance Advisor, a lightweight, read-only agent, had flagged that index two weeks earlier. Recommendations are ranked by database time reclaimed, so the one at the top of the list is the one that actually moves overall latency, not just the slowest individual query. For queries an index can’t fix, the Performance Advisor proposes an AI-generated rewrite with a predicted improvement and a side-by-side execution plan comparison, so you can validate before touching anything. It never changes your schema; every recommendation waits for a human to review and apply. Alex creates the index on a Tuesday afternoon. The 2 AM page simply never happens.
Wednesday, 11:40 AM: The Autoscaler Does Its Job #
Marketing launches a campaign. Traffic triples. The Horizontal Pod Autoscaler does exactly what it’s supposed to do and scales from 10 pods to 80, and each new pod opens its own database connections on startup. PostgreSQL’s default max_connections is 100, a number last revised when “web scale” meant a beige tower under someone’s desk. So at the exact moment the application gets the most traffic it has ever seen, the database starts refusing connections. The autoscaler, technically, did nothing wrong.
With DBO: the application opens those 400 connections to the DBO proxy, which multiplexes them over a small, controlled pool to the database. The database sees a predictable connection count no matter what the pod autoscaler is doing. And most of the extra read traffic never reaches the database at all: DBO’s cache learns the workload and serves read-heavy queries from memory, adding only sub-millisecond latency on the way in and returning cache hits up to 400x faster. Cache invalidation, the part everyone warns you about, happens automatically by observing writes on the wire, so it works on Amazon RDS, Google Cloud SQL, or self-hosted with no privileged access to database internals. On read-heavy workloads, teams typically see up to 10x lower database compute consumption and 30%+ infrastructure cost reduction.
Autonomous caching is one of the most effective ways to optimize read-heavy workloads, and Cast AI’s approach is brilliantly executed. DBO removes the need for manual tuning while delivering real-time performance gains and cost reductions.
- Dekel Shavit, Senior Director of Engineering, Akamai
Friday, 4:50 PM: The Mystery Slow Report #
Someone from the business asks why the monthly report takes 11 seconds. Nobody knows. pg_stat_statements technically contains the answer, in the same sense that a core dump technically contains the answer.
With DBO: Alex opens the instance dashboard: health metrics, query details, connection stats, cache hit rates, and advisor recommendations in one view. The report query is sitting at the top of the list with a suggested fix attached. Behind all of this is one shared model of each database instance. The slow query shows up with the connections, cache behavior, and load around it, which is what turns a list of problems into a prioritized plan. Alex closes the laptop at 4:55.
Getting Started #
Start at dbo.cast.ai. A guided setup wizard connects your cloud account with a read-only IAM role and runs automated discovery, and within about 10 minutes you’ll see your database instances ranked by optimization opportunity, with a Best Candidate and projected improvements called out, so you’re not picking blind.
The Performance Advisor starts working as soon as the agent is deployed (no proxy routing required), with first recommendations in about 30 minutes. Caching and connection pooling activate when you point your application’s connection string at the DBO proxy endpoint: one config change, no code changes. Enable features one at a time, in whatever order fits your rollout. DBO runs on Kubernetes or Amazon ECS, supports PostgreSQL and MySQL (including Aurora), and works with AWS and Google Cloud.
One data residency note worth making explicit: DBO runs entirely within your infrastructure. Cached data lives in DBO’s in-cluster memory and never leaves your environment. For query rewrite analysis, the Performance Advisor sends only the anonymized, normalised query template: parameter values and identifiers are stripped and replaced with placeholders. No query values, result data, or identifiers leave your cluster. Your data stays where it lives.
DBO is part of Cast AI’s infrastructure optimization platform, the same one that automates Kubernetes rightsizing, Spot instance management, and autoscaling for compute workloads. If you’ve already optimized the application layer, the database is the last bottleneck left in the stack.
We hear Alex sleeps much better now.
Start with DBO today at dbo.cast.ai. Want to see it in action first? Book a demo.