Database Scaling Techniques: Match the Bottleneck

A single primary may own every read and write, but a slow application response does not prove that the database needs distribution. First follow one request through connection acquisition, query planning, lock waits, CPU, memory, storage I/O, and response serialization. A missing index or an unbounded query should be fixed before topology hides it.

Scale architecture only after the evidence names a capacity or availability limit. A larger instance may be the simplest safe step; replicas, partitions, caches, and shards each solve a narrower bottleneck and add routing, consistency, or operational costs.

A read replica is a copy of the primary that serves reads. The app sends SELECTs to replicas and writes to the primary. Replication lag means replicas can be slightly behind — fine for product pages, risky for "read your write" right after checkout unless you route that path to primary.

When to use: read-heavy workloads (catalogs, feeds, reports). When to skip: write-dominated systems where the primary is already the bottleneck — replicas do not multiply write capacity.

Sharding partitions data across separate databases (shards) by a key — user ID, tenant ID, region. Each shard holds a slice; no single node holds the whole dataset. Writes and storage scale with shard count, but cross-shard joins and transactions get hard.

When to use: data or write volume exceeds one primary even with replicas. When not to: early products still fine on one Postgres — sharding is operationally expensive (rebalancing, hot keys, routing).

Partitioning divides a large table into pieces inside the same database — by range (date), list (region), or hash. Queries that prune partitions scan less data; old partitions can be archived or dropped cheaply.

Unlike sharding, you still have one logical database and usually one primary for writes. Partitioning is often the right move before sharding when a single huge table (events, orders by month) dominates I/O.

When to use: time-series or huge fact tables with predictable filters. When not to: small tables or random access by keys that never prune.

Caching keeps reusable results in a faster layer so repeated product requests do not execute the same query. Flow: app → cache → on miss → database → attempt to populate → response. The useful result is measured origin work avoided without violating freshness, not a generic hit-rate target.

When to use: frequently read data with an explicit staleness allowance. When not to: write-sensitive balances, permissions, or personalized responses without safe keys and invalidation. See Caching 101 for layers and eviction; this section only places caching in the database-scaling decision.

There is no universal cache → replica → partition → shard ladder. Start with the wait you measured. Repeated identical reads suggest a cache; many independent reads saturating the primary suggest replicas; scans over one very large table suggest partitioning; write throughput or storage beyond one node may justify sharding. Sometimes an index, batch job, queue, or larger instance is the correct next move.

Run the decision on one checkout request: if it waits for a pool slot, reduce query duration or control concurrency; if it waits on a lock, shorten transactions or remove hot writes; if a read saturates the primary, test a replica with a freshness rule; if one tenant dominates writes, test shard-key distribution before splitting data.