How do you scale databases?

Question

Accepted Answer

Databases often become a **bottleneck** as systems grow. Scaling them involves techniques like **replication** (copies for read scaling and availability), **sharding** (splitting data across servers), **caching**, and choosing appropriate database types.

## Replication — copies of the data

```text
REPLICATION → maintain COPIES of the database across servers:
  → PRIMARY (writes) + REPLICAS (copies):
    - READ SCALING → direct reads to replicas (offload the primary) → handle more reads
    - AVAILABILITY → a replica can take over if the primary fails (failover)
  ⚠️ replication lag → replicas may be slightly behind (eventual consistency for reads)
→ great for READ-heavy workloads and availability (most apps are read-heavy)
```

## Sharding — splitting the data

```text
SHARDING → split (partition) data across MULTIPLE database servers (each holds a SUBSET):
  → distribute by a SHARD KEY (e.g. user ID) → each shard handles part of the data/load
  → scales WRITES and storage horizontally (beyond one server's capacity)
  ⚠️ complex: choosing a good shard key (even distribution), cross-shard queries are hard,
    rebalancing → significant complexity
→ for when data/write volume exceeds a single server (large scale)
```

## Other scaling techniques

```text
✓ CACHING → cache query results / hot data (Redis) → big reduction in DB load (often the
  first and most impactful step)
✓ INDEXING & query optimization → make queries efficient (before scaling out)
✓ Read/write SPLITTING; connection pooling; denormalization (for read performance)
✓ Choose the right DATABASE (some scale horizontally more easily — NoSQL)
✓ Vertical scaling (bigger DB server) → simple first step, but limited
```

## Why it matters

Understanding how to scale databases is valuable because the **database is often the bottleneck** as systems grow, so scaling it is a critical, common system-design challenge, making this important knowledge.

As systems scale, the database frequently becomes the limiting factor (a single database can only handle so much load and data), making database scaling a key concern.

Understanding **replication** — maintaining copies (a primary for writes plus replicas) to enable **read scaling** (directing reads to replicas to offload the primary, valuable since most apps are read-heavy) and **availability** (a replica taking over on failure) — is a fundamental, widely-used technique, along with understanding the caveat of replication lag (eventual consistency for replica reads).

Understanding **sharding** — splitting data across multiple servers (each holding a subset, distributed by a shard key) to scale **writes and storage** horizontally beyond one server — is essential for very large scale, along with its significant complexity (choosing a good shard key, difficult cross-shard queries, rebalancing).

Understanding **other techniques** — **caching** (often the first and most impactful step, dramatically reducing database load), **indexing and query optimization** (making queries efficient before scaling out), read/write splitting, denormalization, choosing horizontally-scalable databases, and vertical scaling as a simple first step — provides the full toolkit, with the important practical wisdom that caching and optimization often come before the complexity of sharding.

Since the database is commonly the scaling bottleneck and scaling it (via replication for reads/availability, sharding for writes/storage, caching, and optimization) is a critical, common challenge, and since understanding these techniques and their trade-offs is important for designing scalable systems, understanding how to scale databases is valuable, practically-important system-design knowledge — addressing a critical, common bottleneck, central to scaling real systems, and requiring understanding of replication, sharding, caching, and optimization to handle the database scaling that growing systems inevitably need.