Replication vs sharding: when to scale a database
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?
Key takeaway. Read bottleneck — replicas. Write or disk size — shards. Profile load and indexes first: sharding "for later" is almost always more expensive than slaves and cache.
The Architect's Dilemma
Choosing a strategy depends on exactly where your "bottleneck" is: in reading (Read) or writing (Write).
Fig 1. Left: Master-Slave Replication. Right: Horizontal Sharding.
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.
Next steps
We can review your load profile: high-load engineering, load testing, or a 2-minute estimate quiz.
Related services
Replication vs sharding FAQ
If the bottleneck is reads (catalog, media, storefront) — replicas first (master + slaves). If writes or disk no longer fit on one master — shards. "A bit more RAM" fixes neither when CPU is already pegged.
While 80–90% of load is SELECT and the master still keeps up with writes. PostgreSQL streaming or MySQL binlog cover reads. The cost is replication lag: a user may not see their write on a replica immediately.
You lose JOINs and ACID transactions across shards; backups and migrations get harder. Split by key when data or writes truly no longer fit on one node — not "just in case" on day one.
Profile read vs write, slow queries, indexes, cache. Replicas plus Redis often suffice. Sharding is the next step after read replicas are exhausted.
Want to apply this in practice?
Tell us about your system — we’ll propose a work plan and the metrics worth fixing in an SLA/SLO.
Related articles
SLA 99.9% vs 99.99%: when paying for extra nines is a waste
SLA and availability for business: downtime in minutes at 99.9%, 99.95%, and 99.99%, when the baseline is enough, and when you need contract penalties and 24/7 on-call.
Read ArticleB2B customer cabinet MVP: 7 screens partners actually open
B2B customer / dealer cabinet MVP: the 7 screens that matter, what to defer to v2, budget and timeline ranges, and an acceptance checklist for partner portals.
Read ArticleSEO Is No Longer Enough: Stores Need APIs for AI Agents
SEO finds the customer, API lets the AI agent buy. OpenAPI for e-commerce and SMB: perimeter checklist, risks in ₽, and a "when to build" framework.
Read ArticleWhite-label SCADA for integrators: go to market in weeks, not years
Why system integrators choose ready cloud SCADA over building from scratch: Modbus → MQTT, live monitoring, alarms, white-label branding, pilot in 2–4 weeks.
Read Article