Database Sharding vs Replication: Scaling Writes vs Scaling Reads
Architectural comparison of database sharding vs replication. Learn how replication scales reads while sharding scales write throughput and dataset volume.
Database Replication
Mirroring identical data across primary and replica nodes.
- Simple implementation supported natively by PostgreSQL, MySQL, and MongoDB
- Near-infinite read scaling by attaching read-only follower replicas
- Automatic failover: secondary replica promotes to primary during hardware failure
- Does not scale write capacity; all write operations still bottleneck on the single primary
- Does not scale storage capacity; every replica must store the entire dataset
- Replication lag can cause stale reads on replica queries
Database Sharding
Splitting data subsets across discrete independent database instances.
- Scales both write throughput and disk capacity linearly as you add shards
- Limits blast radius: a failure in Shard 3 does not take down users hosted on Shard 1
- Massive application complexity: cross-shard joins and distributed transactions are costly
- Re-sharding and partition key selection errors require painful database migrations
- Operational maintenance overhead of managing dozens of independent database clusters
Always start with database replication to scale read operations and secure high availability. Only introduce database sharding when your write throughput or total dataset volume fundamentally exceeds the capacity of the largest vertical database instance available.
Feature & Specification Matrix
| Criterion | Database Replication | Database Sharding | Winner |
|---|---|---|---|
| Primary Scaling Dimension | Scales Read throughput & High Availability | Scales Write throughput & Total Storage Volume | Database Sharding |
| Implementation Complexity | Low; handled transparently by database engines | High; requires routing proxies and partition key planning | Database Replication |
| Cross-Record Joins | Full native SQL JOIN support on any node | Cross-shard joins require two-phase network aggregations | Database Replication |
| Hardware Failure Impact | Replica promotes to master; zero data loss with synchronous replication | Outage affects only users located on that specific shard | Database Replication |
1. The Partition Key Dilemma
In sharding, choosing the shard key determines your system's fate. A poorly chosen key (such as created_at timestamp) directs all current write traffic to a single active shard, creating a severe hotspot. A good partition key (such as tenant_id or user_uuid hash) evenly distributes write and read operations across all shard nodes.
When to choose Database Replication
- Your read-to-write ratio is 80:20 or higher.
- Your total dataset fits on high-capacity cloud NVMe storage (e.g. up to 16 TB).
- You need zero-downtime failover without rewriting your application queries.
When to choose Database Sharding
- Your write throughput is saturating primary node CPU/IOPS limits.
- Your dataset is growing by multiple terabytes per month.
- You have natural horizontal boundaries (e.g., enterprise tenant_id).
Sharding, Replication and System Design: High-Scale Architecture
Want hands-on code examples and end-to-end setup instructions? Read the comprehensive guide published directly on Aditya's engineering blog.
Frequently Asked Questions
Can you combine sharding and replication?
Yes. In production architectures (such as MongoDB sharded clusters or Vitess for MySQL), each individual shard is itself a replicated cluster with one primary and multiple read replicas.