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 teams know well: when the database is struggling and pressure is on, adding capacity is the quick move you can make. The harder questions: which patterns are driving load, how often they are executing, and whether the problem is query related, require visibility most teams don't have at that moment.

Read replicas solve a real problem. They distribute traffic and buy headroom when volume is the constraint. The issue surfaces when they become the default response to every performance problem.

• Replicas scale volume, not efficiency. Many read performance problems are not volume problems, they are query problems. Every replica added to handle a high-cost query is infrastructure spend coupled to that unresolved pattern.
• Replication lag introduces its own complexity. As replica count grows, so does the work. WAL streaming, replication lag monitoring, connection pooling per replica and failover logic all give your team more to manage at every step.
• The most expensive queries are rarely spread evenly. In most production systems, a small number of query patterns account for the majority of database load. Adding replicas spreads that load without addressing whether those patterns should be executing at that frequency at all.

The decision to add a replica should start with full visibility into what your database is actually doing. If it's high-frequency reads on stable data, caching at the query layer is cheaper and more durable. If it's expensive queries from missing indexes, the replica just defers the work.

Readyset RDST is a free CLI tool that connects directly to your Postgres or MySQL database and surfaces that visibility in a few quick commands. You might find out you don't need that replica at all, or some of the ones you already have. For a deeper look at where complexity actually lives in Postgres scaling architectures, this post is worth reading.

🔍 What We're Watching in the Database Ecosystem

2026 MySQL Ecosystem Performance Benchmark Report

Percona published their 2026 benchmark report comparing MySQL 5.7, 8.0, 8.4, 9.6, Percona Server, and MariaDB across read-only, read-write, and write-only workloads at various concurrency levels. If you are planning an upgrade or evaluating engines, this is a comprehensive comparison.

Keeping a Postgres Queue Healthy

A detailed look from PlanetScale at how MVCC-based dead tuple accumulation quietly degrades Postgres job queue performance over time, and what newer Postgres features like FOR UPDATE SKIP LOCKED and batch processing do and do not solve. A useful read for any team using Postgres as a job queue.

In Case You Missed It

Live Webinar: 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 will run RDST against a database fleet, break down what is driving load, and show how to surface query patterns, execution costs, and optimization opportunities, including when to cache and when to fix the query, directly from your terminal. Register here.

New on our Blog:

Caching real GitLab queries on Azure Postgres with Readyset: Vinicius Grippa ran real GitLab CE traffic through Readyset on Azure Postgres and found that 83% of query shapes are cacheable, the slowest query dropped from 85ms to 3ms, and the Postgres instance scaled down from $577/mo to $140/mo at the same throughput.

Replication Internals: Decoding the MySQL Binary Log Part 11: The final post in Marcelo's 11 part MySQL replication internals series is live! In this post, Marcelo dives into the new serialization framework MySQL 8.4 introduced for tagged GTIDs. If you're working with MySQL internals, this entire series is a great read.

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