DB Scaling: Replication or Sharding?

Your startup took off. But joy turns into panic: the database is "suffocating". CPU is maxed out, queries hang for 5 seconds. Just "adding RAM" doesn't help anymore. It's time to choose the architectural pill: Replication or Sharding?

The Architect's Dilemma

Choosing a strategy depends on exactly where your "bottleneck" is: in reading (Read) or writing (Write).

1. Replication: Scaling Reads

Essence: You have one "Boss" (Master) who accepts all changes, and many "Subordinates" (Slaves) who only serve data.

• When to use: 80-90% of the load is reading (Read-heavy). Typical for media, blogs, e-commerce catalogs.
• Pros: Easy to configure (PostgreSQL Streaming Replication, MySQL Binlog). Data is duplicated (backup).
• Cons: Replication Lag. You wrote data to Master, but it appears on Slave after 100ms. The user might not see their comment immediately.

2. Sharding: Scaling Writes

Essence: Master can't cope with writing. We cut the database into pieces. Users A-M go to Server 1, N-Z to Server 2.

• When to use: Data is so large it doesn't fit on one disk. Or when one Master can't keep up with writing (Write-heavy).
• Pros: Theoretically infinite scaling.
• Cons: It hurts. You lose ACID transactions between shards. You lose JOIN (how to join a table from Server 1 and Server 2?). Backups become a nightmare.

NineLab Verdict

Golden Rule: Postpone sharding until the last moment. It's a "nuclear button".

First — indexes. Then — caching (Redis). Then — replication. And only if you have traffic level of Telegram or Uber — sharding. Don't complicate architecture prematurely.