Database Sharding vs. Partitioning vs. Read Replicas: Choosing a Horizontal Scaling Strategy

A single database server eventually runs out of one of three things: read capacity, manageable table size, or write capacity. Read replicas, partitioning, and sharding each answer exactly one of those problems, and using the wrong one adds operational cost without fixing the actual bottleneck.

What Each Technique Actually Moves: Reads, Table Size, or Write Load

A read replica is an asynchronous copy of a primary database. The application keeps writing to the primary and sends selected read queries to one or more replicas instead. According to AWS's documentation, Amazon RDS supports up to 15 read replicas for MySQL, PostgreSQL, and MariaDB instances, and up to 5 for Oracle, using each engine's native asynchronous replication. Because replication is asynchronous, a replica can lag behind the primary by a measurable amount, which is why AWS surfaces ReplicaLag as a monitored metric rather than treating replicas as perfectly current copies. Read replicas raise read throughput. They do nothing for write throughput, because every write still goes through the single primary.

Partitioning divides one large table into smaller physical pieces that still live on the same server. PostgreSQL's declarative partitioning, available since version 10, supports range, list, and hash partition methods, and the partitioned table itself holds no data of its own. The database's query planner can skip partitions that a query's filter conditions rule out, which is why partitioning mainly helps when queries consistently filter on the partition key, such as a date range or a tenant ID. Partitioning does not add another machine to the system. It reorganizes data that was already going to live on one server so the server can work with it more efficiently.

Sharding splits data across separate database servers, each holding a distinct subset of rows. This is the step that actually adds machines to the write path. In MongoDB's sharding model, a shard key determines which shard each document lives on, and the key's cardinality sets a hard ceiling on how many shards can usefully exist. MongoDB's own documentation gives the example of a shard key with only seven possible values: no matter how many shard servers you add, the cluster can never use more than seven of them, because each unique key value can only live in one chunk at a time. Sharding raises both write and storage capacity, but it turns the data layer into a distributed system, with cross-shard queries, rebalancing, and shard-key migration all becoming real operational work.

How Read Replicas, Partitioning, and Sharding Compare Across the Metrics That Matter

No single source lists all three techniques side by side on the same dimensions. The table below arranges figures and characteristics pulled from the AWS, PostgreSQL, and MongoDB documentation cited above into one comparison.

How AWS, PostgreSQL, and MongoDB Implement Each Pattern

The specifics matter more than the general idea. On Amazon RDS, a read replica is created from a source instance identifier, and RDS keeps it current using the database engine's own asynchronous replication rather than a proprietary mechanism, which is why replica behavior differs slightly between MySQL, PostgreSQL, and SQL Server. Promoting a replica to stand in for a failed primary breaks that replication relationship permanently, so a promoted replica becomes a new, independent primary rather than a temporary stand-in.

PostgreSQL's declarative partitioning requires picking a partitioning method, range, list, or hash, along with the column or columns used as the partition key. A common pattern is range partitioning by date, where each partition covers one time period and old partitions can be dropped outright instead of deleted row by row. The tradeoff is that partitioning only pays off when queries actually filter on the partition key. A query that scans across every date range gains nothing from date-based partitions and may even lose a small amount of planning overhead.

MongoDB's sharding documentation is explicit that shard key cardinality sets a hard limit on cluster scalability, because each unique shard key value can exist in only one chunk at a time. A field with seven possible values caps a cluster at seven usable chunks regardless of how many shard servers exist. AWS's replica ceiling and MongoDB's shard-key cardinality ceiling look unrelated at first, since one caps read copies and the other caps write distribution, but they describe the same underlying limit from opposite sides of the workload: horizontal scaling is only as effective as the least flexible choice made up front, replica count on the read side, key cardinality on the write side. Vendors that avoid manual key selection do so specifically to sidestep this constraint. Aerospike, for instance, describes hashing every record into one of 4,096 internal partitions and rebalancing them automatically as nodes are added, which is a vendor design choice rather than a universal default, and is disclosed here as such.

Choosing a Scaling Path Without Over-Engineering the Database

The three techniques are not competing options for the same problem. A team with a read-heavy application and a fast-growing write volume may eventually need all three at once, replicas under the primary, partitioned tables on each shard, and shard keys chosen with enough cardinality to keep adding servers useful. MongoDB's own architecture reflects this: individual shards are commonly deployed as replica sets, combining sharding for write distribution with replication for durability within each shard.

The open question for most teams is not which technique is best but which bottleneck is real right now. Read replica lag, partition key mismatch, and shard key cardinality are three different failure modes, and choosing sharding before confirming that write throughput is the actual constraint adds a distributed system's worth of operational cost to a problem that a partitioned table or a couple of replicas would have solved. Because shard keys are difficult to change once chosen, the cost of guessing wrong is asymmetric: adding a read replica that turns out to be unnecessary costs an idle instance, while sharding on the wrong key can mean a full resharding operation before the cluster works as intended.