Decision: Sharding or Replication (scaling)?

The database scaling decision depends on whether the bottleneck is reads or writes and whether the data fits on a single node. The wrong strategy means unnecessary complexity or an unresolved bottleneck. This tree first reminds you of the cheapest and simplest options (vertical scaling, caching) and then helps you choose correctly between read replicas and sharding.

Have you tried the simplest path first: vertical scaling and query tuning?

Before moving to a distributed architecture, take the cheapest win: growing the hardware (CPU/RAM/IOPS), adding missing indexes and fixing expensive queries solves most bottlenecks. Add complexity only when these are exhausted.

• No / I have not hit the limit yet
• Yes, vertical scaling and tuning are not enough

Is the bottleneck reads, or writes/data volume?

Isolate the source of the scaling problem: are many read queries choking a single node (read-heavy), or does the write rate or total data size exceed a single node's capacity (write/volume-heavy)? This distinction is the fundamental difference between replicas and sharding.

• Read traffic dominates, writes fit on a single node
• Write rate or data volume exceeds a single node

Are reads repetitive/cacheable, or fresh and varied?

Split the read bottleneck one step further: are the same results read again and again (a cache is very effective), or do reads request varied, broad and current data (extra read capacity is needed)? This decides between a cache layer and read replicas.

• The same data is read repeatedly, slight staleness is acceptable
• Varied/fresh reads, raw read capacity is needed

Recommendation: vertical scaling + query tuning first

The first and cheapest path before moving to a distributed architecture. Growing the hardware and fixing queries/indexes solves most scaling problems without adding operational complexity.

Recommendation: read replicas (read scaling)

Writes stay on a single node (the primary) while read traffic is distributed to one or more replicas. It is the standard way to increase raw read capacity and resilience for read-heavy workloads.

Recommendation: cache layer

Keeping frequently re-read results in a fast in-memory layer drastically reduces database load. With the right pattern it answers without going to the database, lowering both latency and load.

Recommendation: sharding (write/data scaling)

Data is split by a shard key and distributed across multiple independent nodes; each node owns a slice of the data and its writes. It is the way to scale write rate and total data volume, but it adds significant complexity.