Readyset Weekly
Database insights for teams running Postgres and MySQL, delivered weekly.
What Your Agent Does to the Database When It Retries
If you are running an AI agent against a database, your query count is shaped as much by what fails as by what succeeds. When a tool call errors, times out, or returns something the model dislikes, t…
Your Agent’s Memory Is a Hot Read Path
If you are running an AI agent in production, some of your most repeated reads may be coming from a table you have never thought of as hot. Agent frameworks keep each conversation's state in a databa…
Four Database Checks to Run Before Black Friday
Your holiday code freeze is probably a week or two out, which means the queries your database runs today are largely the ones it will run at peak, just more of them. The common plan is to scale up th…
Why Your Query Stats Can’t Tell You When Something Broke
When a query gets slow, your customer will often notice before you do. The page drags, someone pings on-call, and an engineer opens or to work out what changed. By then the query has often been getti…
How Does Your Replica Know Where It Left Off?
Every replica needs to track its progress and know where to resume if the stream is interrupted. Postgres and MySQL handle this differently, and those differences matter for failover, recovery, and c…
The Cost of Keeping Postgres Healthy: Vacuum, Bloat, and Maintenance
PostgreSQL reported the largest popularity gain of any system in the first half of 2026, and for new projects it's increasingly the default choice. Its extension ecosystem and reliability make it a s…
PostgreSQL 19 Is Almost Here. Here’s What To Know.
PostgreSQL 19 hit its fourth beta on September 24, with a release candidate expected in early October and general availability targeted for the end of the month. The release brings improvements to ta…
MySQL 8.0 Went End-of-Life. Do You Know Which Clock You're On?
On April 30, 2026, MySQL 8.0 reached end of life, which means Oracle's community edition stops receiving security patches. Which clock you're on decides whether you're already exposed, being billed f…
The HTAP Dream Keeps Coming Back
In the space of a few weeks in 2025, two of the biggest names in analytics bought a transactional database. Databricks acquired Neon for about a billion dollars in May, and Snowflake acquired Crunchy…
Garbage Data, Garbage Agents
Garbage in, garbage out becomes more consequential when an AI agent can act on the output. Bad data no longer just produces a bad answer; it can trigger the wrong update, message, or workflow before…
The DBA Shortage That Wasn’t Budgeted For
In DataStrike's 2026 Data Infrastructure Survey, 74% of IT leaders said their budgets would grow this year, and yet only about a third of the organizations surveyed employ a dedicated DBA. Among the…
AI Agents Created 80% of New Databases
Databricks reports that on Neon, its serverless Postgres platform, AI agents now create 80% of all new databases, up from almost none two years earlier. Most of those databases are short-lived, spun…
When Scale-to-Zero Actually Saves You Money
Scale-to-zero is one of the headline features of some serverless databases, and the pitch is easy to like. When a database is idle for a set period, its compute stops and so do the associated compute…
When Ordinary Queries Become Your Most Expensive Workload
Pick one piece of operational data, say an order status. Now count how many systems depend on it: the ops dashboard, notification service, search index, mobile API, nightly analytics job, an AI agent…
Your AI Agent Has Never Seen Your Real Data
An AI agent that performs well in a demo environment is usually running under conditions that allow for that. The dataset is small, the whole schema fits in the context window, and someone is watchin…
Your Database Savings Shouldn’t Expire
Most teams judge database optimization by what it saves the day it's applied. An expensive query is tuned, an instance gets rightsized, a cache is added, and the bill gets smaller. At least for the t…
Caching Shouldn't Be a Part Time Job
As of today, Readyset can do it for you. It already identifies expensive queries and automatically caches them, but now the cache continuously re-evaluates which queries to cache, tunes TTL per query…
Why Cache Maintenance Is Moving Into the Database
Last week we looked at one of the harder problems in caching, which is keeping a cached result correct once the underlying data changes. This week it's worth asking a related question about where the…
When the Data Changes, What Does Your Cache Know?
The hardest part of caching isn't serving a query quickly. It's keeping the cached result correct after the underlying data changes. When a cached result is stale, nothing errors, nothing slows down,…
What Postgres 18's I/O boost helps, and what it doesn't
The headline from the Postgres 18 release in September was a single simple number: up to 3x faster reads from storage, courtesy of a new asynchronous I/O subsystem. PostgreSQL 19 Beta arrived this mo…
The Hidden Work Behind Zero-Downtime Migrations
A schema change tends to sound small when someone describes it. Add a column, change a type, drop a constraint. The migration script is a few lines and the review takes minutes. Run that same change…
Why Cache Invalidation Breaks in Production
Serving a cached query result is usually the easy part. You run the expensive join once, store the result, and serve it fast for subsequent requests. The hard part shows up later, when the underlying…
The 20% of Queries Driving Most of Your Database Load
Database load is rarely spread evenly. When the database starts straining, the instinct is to treat it as a whole-system problem: the database is slow, so the database needs more capacity. But pull a…
How MCP Changes Database Workloads
You have probably spent years thinking carefully about which queries reach your database and where they come from. Connection limits, permission scopes, slow query logs, query review in code review.…
Cloud Infrastructure Costs Are Rising. Is Your Database Ready?
For most of the last two decades, cloud infrastructure got cheaper every year. AWS made more than 100 price cuts between 2006 and 2023. That shaped how engineering teams make decisions: if something…
Your Database Probably Doesn’t Need Another Read Replica
OpenAI runs ChatGPT on a single PostgreSQL primary and close to 50 read replicas. That architecture gets held up as a scaling achievement, and it is, but it also highlights a pattern most engineering…
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…
Database Performance is a Three-Layer Problem
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…
MySQL 9.7 LTS: What Production Teams Need to Know
MySQL 9.7.0 LTS was released this week. For most teams running MySQL in production, this is the upgrade decision many have deferred since 8.4. Since the 8.4 LTS release in 2024, MySQL has been shippi…
The Hidden Cost of Slow Queries That Nobody Fixes
Most teams have a version of the same list: queries they know are slow or disproportionately expensive. They show up in logs and dashboards, get tickets, get deprioritized, and get pushed to the next…
Caching in the Age of AI-Generated SQL
Traditional query caching assumes something that is no longer always true: that a human wrote the query, understood its behavior, and could decide whether it should be cached. When SQL was written by…
How to Know Which Queries Are Actually Worth Caching
Adding a cache in front of your database sounds straightforward until you have to decide what goes in it. Cache everything, and you waste memory on queries that rarely repeat. Cache the wrong things,…
Connection Pooling: An Overlooked Bottleneck in High-Concurrency Systems
Most database performance conversations start with queries: slow joins, missing indexes, unoptimized aggregations. Connection pooling rarely makes that list, which is exactly why it becomes a problem…
Why LLMs Write Incorrect SQL (and What That Means for Your Database)
AI-assisted development has made it easier than ever to generate SQL quickly. The problem is that quick and correct are not the same thing, and with databases, the gap between the two has real conseq…
Application Caching vs SQL Caching: Where the Complexity Lives
When read latency starts to climb, adding a caching layer is usually one of the first solutions teams reach for. There are two common ways to go about it: build a caching layer at the application lev…
What to Consider Before You Shard Your Database
Sharding is often presented as the inevitable next step once a database outgrows a single node. But many teams underestimate the complexity it introduces and adopt it before fully exploring the trade…
Why Your P95 Latency Explodes Before Your CPU Does
P95 or P99 latency often spikes while CPU still looks "fine." Databases rarely fail exactly at 100% CPU, they degrade when queueing, contention, and coordination overhead begin compounding under load…
Reducing Database Storage Costs Without Hurting Performance
Storage growth is predictable, but storage bills aren't. In write-heavy systems especially, expanding datasets quietly turns storage into a persistent cost center. Here are practical ways to reduce s…
Vertical Scaling vs. Architectural Changes: When to Upgrade Hardware and When to Rethink the Stack
When performance degrades, the fastest reaction is often to add CPU or memory. Sometimes that works. But at scale, hardware stops addressing the underlying bottleneck. That's when architecture, not c…
Query Caching vs. Read Replicas: Which Reduces Day-2 Operational Drag?
Last week we compared query caching and read replicas through a cost lens; this week, we're looking at what matters once the system is live. Day-2 operations are where scaling decisions either fade i…
Query Caching vs. Read Replicas: Which Saves You More Money?
This week, we're breaking down a common scaling decision: read replicas versus query caching, and which one actually reduces cost as read traffic grows. Below are a few practical considerations when…
Optimizing PostgreSQL Query Execution Plans for Faster Performance
Last week we looked at how MySQL execution plans shape performance at scale. This week, we turn to PostgreSQL. Its planner is more powerful, but also easier to mislead if you are not paying attention…
Optimizing MySQL Query Execution Plans for Faster Performance
When MySQL performance degrades, the root cause is often hiding in the execution plan, not the query text itself. At scale, cost-based decisions that look reasonable on small data sets can compound i…
Scaling a Multi-Tenant SaaS Database Without Breaking Performance
Multi-tenant databases work well at low scale, but shared resources magnify inefficiencies as tenant count and traffic grow. The first problems rarely show up as obviously slow queries. Instead, they…
Eliminate Redundant Work with Targeted Caching
Most database performance problems aren't caused by slow queries, but by doing the same work repeatedly. At scale, redundancy becomes the dominant cost even when individual queries are "fast." Target…
Attack Replica Lag at the Source
Replica lag isn't always a replication problem. It's usually excess work on the primary. If replicas are falling behind, start here: 1. Reduce write amplification first: Extra index updates and redun…
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 unti…
Why Replica Cost Creeps Back In and How to Prevent It
Last week, we covered the levers for reducing read replica cost: improving query hygiene, pooling connections, reducing lag, and eliminating redundant work. This week is about where those fixes break…
The Real Cost of Read Replicas (and How to Reduce It)
Read replicas often look like an easy scaling win, but the real cost shows up later. Each replica still parses, plans, and executes full queries, multiplying work and cloud spend and often quietly am…
Edge Caching vs. Query Caching: Choosing the Right Approach for Scalability
Teams often reach for edge caching to cut latency, and it works well for static or pre-rendered content. But when the bottleneck is the database, not the network, query caching is the solution you ne…
The Role of Connection Pooling in High-Throughput Applications
High-throughput systems usually fail not because queries are slow but because the database gets overwhelmed by connection churn. A good pool smooths spikes, reuses backends, and prevents short-lived…
Eventual Consistency vs. Strong Consistency: What’s Right for Your Application?
Consistency problems rarely show up as clear architectural flaws. They surface as latency, replica lag, and hotspots because reads and writes compete on the primary. Most systems already rely on some…
Making Sense of Adaptive or Feedback-Driven Balancing
Round-robin spreads load, read/write splitting separates intent, and latency-aware routing tracks speed. Adaptive balancing closes the loop by adjusting in real time based on live metrics such as CPU…
Being Aware of Latency-Aware Routing
When replicas span regions or clouds, round-robin and simple read/write splitting hit their limits. Latency-aware routing uses live query and health metrics to direct traffic to the lowest-latency re…
Navigating Read/write Splitting
After round-robin balancing, the next step is read/write splitting. It routes reads to replicas and writes to the primary. Done right, it scales reads efficiently. Done wrong, it causes lag and incon…
Round-Robin Load Balancing, the Right Way
Round-robin load balancing is the simplest way to spread reads across database replicas. It's often the first scaling step for teams moving past a single node, but simplicity doesn't mean "set and fo…
Load Balancing for Distributed Databases
As your app scales beyond a single database node, bottlenecks build up gradually through uneven workloads, lagging replicas, and overloaded primaries. Load balancing smooths those out before they cau…
When to Use SELECT FOR UPDATE
Row-level locking is often dismissed as a performance killer, but when used strategically, can actually improve system reliability and throughput. By locking rows as they are read, you prevent compet…
Digging Deeper on Partitioning Part 2: Key-Based Partitions
Last week, we covered time-based partitioning. This week, we're looking at key-based partitioning, which splits tables by a column like , , or region. It's particularly effective in multi-tenant SaaS…
Digging Deeper on Partitioning Part 1: Time-Based Partitions
Last week we covered how partitioning avoids bottlenecks. This week we'll look at best practices for time-based partitioning in Postgres and MySQL. Pick the right interval: Use daily partitions for h…
How Partitioning Prevents Database Bottlenecks
As tables grow, even well-indexed queries can slow to a crawl. Partitioning splits a large table into smaller, more manageable chunks. That way, the database only scans what is relevant. Done right,…
Materialized Views vs. Query Caching: Which One Should You Use?
When queries start dragging, engineers often reach for materialized views or query caching. Both reduce redundant computation, but the better fit depends on freshness needs, write patterns, and workl…
How to Avoid Gap Locks in MySQL
Gap locks are a MySQL behavior many teams discover only after they cause production issues. They enforce isolation in InnoDB but can create unexpected contention in simple queries. For example: This…
Heavyweight Locks and How To Watch Out for Them
Database locks protect consistency, but not all are equal. Row-level locks are common and usually manageable in high-concurrency workloads, but heavyweight locks that control tables, indexes, or sche…
Reducing Write Hotspots Before They’re Problematic
In Postgres and MySQL, write hotspots can turn into choke points fast: concurrent updates serialize, transactions pile up, and tail latency climbs. To stay ahead of the pile-up: For MySQL and Postgre…
Using the Right Isolation Level for Performance Under Load
Higher isolation levels increase consistency but reduce throughput and raise contention. Most OLTP workloads don't need . Here's what to use instead: is usually enough: It prevents dirty reads withou…
How to Keep Transactions Short and Scoped
Long transactions are a common source of lock contention, replication lag, and unpredictable performance in high-traffic databases. Here are a few tips for keeping transactions short and tightly scop…
How to Reduce Contention in High-Traffic Databases
As database traffic grows, so does the risk of contention and locking. These issues can silently stall reads, block writes, and trigger cascading slowdowns. Here's how to spot and fix contention befo…
Scaling PostgreSQL Without Sharding: Alternatives That Preserve SQL Semantics
Sharding is a well-known method for scaling Postgres, but, like in MySQL, it comes with significant tradeoffs: broken joins, additional application logic, weaker transaction support, and shard key mi…
How to Scale MySQL Without Sharding
Sharding (splitting your data across databases) is a well-known strategy for scaling MySQL. However, it comes at a high cost: complex joins, extra application logic, weaker transaction support, compl…
When Query Optimization Isn’t Enough
You’ve optimized your queries. You’ve tuned indexes, analyzed execution plans, and warmed the cache. But your database still lags. Your users are still impacted. Why? Because even fast queries, when…
Should You Use Read Replicas or Caching?
Replicas are a common way to scale read traffic, but they don’t reduce compute. Every query still gets parsed, planned, and executed. Add lag and infrastructure cost, and teams hit scaling limits fas…
The Hidden Performance Costs of ORMs and How to Avoid Them
ORMs can simplify development, but often slow down your database. From N+1 queries to redundant joins, they usually generate inefficient SQL that kills performance at scale. Here are a few common pit…
Identifying and Fixing Slow Queries
Slow database queries can significantly degrade application performance, user experience, and more. However, a few minor changes can dramatically reduce query latency. Start by identifying slow queri…
How To Reduce Query Latency Without Changing Your Code
You don’t need to rewrite application code to improve query performance; instead, optimize your SQL structure. A few examples: Use instead of for subqueries; PostgreSQL’s planner often handles more e…
What’s Slowing Down Your Postgres Queries (And How to Speed Them Up)
Got slow PostgreSQL queries? It’s often more than just SQL, issues with the planner, memory settings, or state states may be the real culprits. Here’s how to start troubleshooting: Get real performan…
What’s Slowing Down Your MySQL Queries (And How to Speed Them Up)
Not all slow MySQL queries stem from bad schemas, sometimes it’s a subtle misconfig, missing indexes, or outdated assumptions. Here’s what to check first: Start with : Check how MySQL plans to execut…
Why Your Indexes Aren’t Helping
Indexes are supposed to accelerate queries, but poor design can bloat storage and slow things down. Make them work smarter, not harder. In PostgreSQL: Identify deadweight indexes with by checking for…
Why OFFSET and LIMIT Pagination Breaks at Scale and What to Use Instead
Using and to paginate queries in PostgreSQL or MySQL forces the database to scan and discard all skipped rows before returning the next page. That’s fine for small datasets, but for large ones, the d…
Why Autovacuum Might Be Slowing You Down and How to Fix It
Autovacuum keeps PostgreSQL healthy by cleaning up dead tuples, reclaiming storage, maintaining index efficiency, and preventing transaction ID wraparound. However, when it falls behind or isn’t tune…
Why You Can’t Always Trust Query Plans and What To Do About It
Query plans can be misleading. Many engineers rely on alone when debugging slow queries, but without actual runtime data, you’re flying blind. Here’s what you can do about it: In PostgreSQL, always u…