Database Scaling

A single database server has limits on connections, disk I/O, and CPU. Three techniques push past those limits: read replicas, vertical sharding, and horizontal sharding.

Read replicas copy data from the primary asynchronously. Reads go to replicas; writes go to the primary. This works when reads outnumber writes — which describes most web applications. Vertical sharding splits different tables across different databases: users in one, orders in another. Horizontal sharding splits one table across multiple database servers by a shard key. It is powerful but complex — cross-shard joins are impossible, and a bad shard key creates hot spots that defeat the purpose.

Before

Single primary — bottleneck under read load

1// All reads and writes hit one server2Application → Postgres Primary (reads + writes)3 4Problems at scale:5→ CPU saturates on complex read queries6→ Connection pool exhausted7→ One failure domain — no redundancy

After

Primary + read replicas

1// Writes → primary only. Reads spread across replicas.2Application → Postgres Primary      (58 writes/sec)3           ↘ Replica 1  (200 reads/sec)4           ↘ Replica 2  (200 reads/sec)5           ↘ Replica 3  (180 reads/sec)6 7// Rule: always use primary for writes and8//       reads that require the latest data.

Check your understanding

What do read replicas buy you?Show answerHide answer
Answer
Extra read capacity and a failover candidate, with async lag on replicas.
When do you still read the primary?Show answerHide answer
Answer
Writes and any read that must see the latest committed state.
What makes horizontal sharding hard?Show answerHide answer
Answer
Cross-shard joins, rebalancing, and hot shard keys that defeat the split.