The Hidden Cost of “Small” Queries at Scale

Most database outages don't start with slow queries. They start with "small" queries whose per-request cost looks trivial but becomes dominant at scale, silently burning CPU, memory, and network until the system tips over.

1. Measure query volume, not just latency: A 2 ms query at 50k QPS is more dangerous than a single slow outlier, and slow query logs won't catch it. Use pg_stat_statements (Postgres) or MySQL Performance Schema to rank queries by execution count and total cost, not just p95 latency.
2. Look for identical queries across requests: High-frequency lookups are often duplicated across APIs and jobs. Even efficient queries become expensive when repeated independently, so group normalized queries to find redundancy, which often matters more than per-query inefficiency.
3. Watch CPU, not just buffer cache hit rate: A high cache hit ratio doesn't guarantee safety. Even with hot data, SQL still burns CPU, and if CPU rises while I/O stays flat, high-frequency queries are likely the bottleneck that replicas won't fix.
4. Collapse high-frequency reads instead of micro-optimizing them: Shaving milliseconds helps, but eliminating executions helps more. Batch reads, reuse results, or cache stable queries. At scale, removing redundancy beats tuning already-fast SQL.
5. Treat repeatable queries as infrastructure, not application logic: Once a query becomes high-volume and predictable, it stops being business logic and becomes infrastructure. Having every request independently compute the same result doesn't scale.

This is the problem Readyset is designed to solve: automatically turning high-volume, repeatable queries into incrementally maintained results, so databases stop recomputing the same work on every request.

🔍 What We're Watching in the Database Ecosystem

Introducing Lightweight MySQL MCP Server: Secure AI Database Access

This post introduces a minimal MySQL MCP (Model Context Protocol) server that gives AI agents controlled, auditable, read-only access to MySQL databases, showing one way teams can safely expose production data to AI without handing over credentials or risking destructive queries.

Cursor Acquires Graphite

This post covers Graphite's acquisition by Cursor, bringing Graphite's AI-driven code review and merge tooling into Cursor's development environment and signaling that profiling, review, and optimization workflows are moving closer to where code is written and validated.

Why AI Infrastructure Will Face a Reckoning in 2026

This New Stack piece argues that today's AI infrastructure is overbuilt, inefficient, and overfunded and that 2026 will force a reset around cost, utilization, and performance. As AI-generated traffic grows, systems that eliminate redundant work rather than scale brute-force compute will matter more than ever.

In Case You Missed It

As we head into the holiday season and the new year, we want to thank you for reading and wish you a happy holiday!

We will be kicking off 2026 at FOSDEM, where we will be hosting a happy hour (details coming soon) and co-sponsoring the Belgian MySQL, MariaDB, and Friends community dinner on Friday, January 30 (registration here). If you are attending or will be in the area, we would love to connect.