Most teams don't treat database performance as a system. When performance slows down, the usual response is reaching for a fix at the pain point: adding a cache with invalidation logic, adding larger instances or additional replicas, or manually tuning one query. But database performance problems show up in three connected layers, and a gap in any one of them limits what the others can do.
- Before queries reach production: Most developers don't review execution plans before shipping, not because they don't care, but because interpreting them requires a level of database expertise most application engineers don't have. Full table scans and unindexed joins rarely surprise anyone in hindsight. The problem is that nobody looked before they reached production.
- In live production traffic: Query patterns are commonly examined reactively, during incidents, by which point a bad pattern has been executing at full cost for some time. Production traffic changes constantly. Access patterns shift, workloads evolve, and queries can become more expensive over time. Without visibility into how patterns are shifting, teams are always reacting to the last incident rather than getting ahead of the next one.
- At the infrastructure layer: When problems slip through the first two layers, the default response is to scale. More replicas, bigger instances. That treats the symptom, not the cause. The longer the root problem goes unaddressed, the more infrastructure you are paying to work around it.
Database performance isn't solved in one place; it needs coverage across all layers. Most teams are solving for some layers or stitching together multiple systems to manually manage the gaps. At Readyset, we take a different approach: treating database performance as a system rather than a set of isolated fixes. RDST surfaces issues before they reach production, QueryPilot adapts to live traffic, and Readyset's caching engine reduces load in production.
Are LLM Agents Good at Join Order Optimization?
Databricks and UPenn published research on applying LLM agents to finding optimal join orderings, their prototype improved on the Databricks optimizer in 80% of cases. The catch: query optimizers need to pick join orders in milliseconds, so the use case today is offline analysis and recommendation, not real-time optimization. A useful read for anyone thinking about where AI-assisted query optimization is headed!
Claude-Powered AI Coding Agent Deletes Entire Company Database in 9 Seconds
PocketOS founder Jer Crane shared what happened when a Cursor agent running Claude Opus 4.6 encountered a credential mismatch, decided to resolve it independently, and issued a single API call that deleted the production database and all backups in nine seconds. If you are running AI agents anywhere near production infrastructure, Crane's post-mortem on the systemic failures is required reading.
Introducing RDST: The Client-Side SQL Performance Toolkit
This week, we launched RDST, a production-native CLI that connects directly to your Postgres or MySQL database and helps you find, understand, and fix query performance issues before they reach production. It analyzes execution plans, surfaces your most expensive queries, scans your codebase for risky SQL before it ships, and connects directly to Readyset when caching is the right next step.
Plus, RDST is completely free to use under BSL license for as long as you like and works with your Anthropic key or the included trial key. Learn more here.
New on our Blog:
How Readyset Rewrites Your SQL: Inside the Query Transformation Pipeline: A deep look at how Readyset transforms arbitrary SQL into a form its dataflow engine can compile and maintain incrementally, covering decorrelation, derived table inlining, join reordering, and more.
Replication Internals: Decoding the MySQL Binary Log, Part 9: XID_EVENT - Transaction Commit: Marcelo continues the series with the XID_EVENT, the smallest event in the binary log at just 31 bytes, and the one that marks every transactional commit. Part 9 explains how this single 8-byte transaction identifier is the mechanism behind crash-safe replication in MySQL.
Know a database aficionado who'd appreciate this? Forward it their way.