Database Design • Read Replicas & Query RoutingMedium⏱️ ~2 min
When NOT to Use Read Replicas: Alternatives and Tradeoffs
Read replicas are not a universal solution. Several scenarios favor alternative architectures. When most traffic can be served from caches, adding replicas yields minimal benefit. If 95 percent of reads hit a Content Delivery Network (CDN) or in memory cache like Redis, your database handles only 5 percent of read load. Scaling replicas from 1 to 5 reduces database load by 4 percent overall, a marginal gain that does not justify the operational cost and complexity of managing replication, routing, and consistency. In this case, invest in smarter cache invalidation, larger cache capacity, or longer Time To Live (TTL) values.
When you need strict read after write consistency or linearizable reads at scale, asynchronous replicas are the wrong tool. Every read requiring strong consistency must hit the primary, eliminating scaling benefits. Consider synchronous replicas (multi Availability Zone deployments), consensus backed stores like etcd or CockroachDB that use Raft for strong consistency, or leaderless systems like Cassandra or DynamoDB that use quorum reads (read from majority of replicas to guarantee seeing latest write). These alternatives trade higher write latency (synchronous replication adds 1 to 5 milliseconds for cross AZ, 50 to 200 milliseconds cross region) for guaranteed consistency.
Hot write throughput bottlenecks do not benefit from read replicas. If your primary is saturated by writes (say 50,000 writes per second pushing CPU to 90 percent), adding read replicas helps reads but does nothing for write capacity. Worse, replication itself consumes 10 to 30 percent overhead on the primary, potentially making write performance worse. Solutions include sharding (partition data across multiple primaries), write path optimization (batch writes, use async commit, optimize indexes), denormalization (duplicate data to reduce joins and writes), or switching to specialized stores (time series databases for metrics, log aggregation systems for events).
Cost is a real constraint. Each replica costs as much as a primary in compute and storage. For a deployment with 5 replicas, you pay 6 times the single instance cost. Cross region replicas add data egress (typically $0.09 per GB). A service writing 100 GB per day to 3 cross region replicas pays $27 per day just in transfer costs, or roughly $800 per month, before compute. Many teams find caching or denormalization cheaper and simpler.
💡 Key Takeaways
•When 90 to 95 percent of reads hit CDN or application caches, adding read replicas reduces overall load by only 5 to 10 percent, not justifying operational complexity and cost of replication management
•Strict read after write or linearizable consistency requirements force all reads to primary, eliminating replica scaling benefits. Consider synchronous replication, consensus stores (Raft, Paxos), or quorum reads instead
•Write saturated primaries (CPU over 80 percent from writes) do not benefit from read replicas and may worsen due to 10 to 30 percent replication overhead. Solutions include sharding, write optimization, or specialized stores
•Each replica costs as much as primary in compute and storage. Five replicas equal 6 times single instance cost. Cross region replicas writing 100 GB per day incur approximately $800 per month in data egress alone at $0.09 per GB
•Alternative scaling strategies include cache optimization (longer TTL, smarter invalidation), denormalization (duplicate data to avoid joins), sharding (partition across primaries), or purpose built databases (time series, log stores)
📌 Examples
Cache heavy workload: E-commerce site with 100,000 reads per second, 95% cache hit rate. Database sees 5,000 reads per second. Adding 4 replicas reduces database load to 1,250 RPS per instance, but overall system load drops only 4%, minimal impact for added complexity.
Write bottleneck: Social media service writes 60,000 posts per second to primary at 85% CPU. Read replicas help read latency but writes still bottlenecked. Solution: shard posts by user ID across 10 primaries, each handling 6,000 writes per second at comfortable 40% CPU.
Cost analysis: Database writing 200 GB/day replicated to 3 cross region replicas. Transfer cost: 200 GB × 3 regions × $0.09 = $54/day = $1,620/month, plus $3,000/month in replica compute. Alternative: Invest $1,000/month in larger cache cluster, cut database load 80%, eliminate replicas.