Skip to main content

Database Scaling

Databases tend to be the hardest part of a system to scale, for a reason called out back in Scalability: stateless web servers can be trivially duplicated behind a load balancer, but a database holds the one copy of the truth, and duplicating that safely is a much harder problem. Database scaling is the progression of techniques for handling more load, roughly in order of how much complexity each one costs.

The order interviewers expect​

There's a natural progression here, and jumping straight to the most complex option (sharding) without considering the cheaper ones first is a common tell that a candidate is pattern-matching rather than reasoning about the actual bottleneck:

System Design Lab
  1. Query and index optimization first. A slow query against a table missing an obvious index is the cheapest possible fix — no new infrastructure, no new failure modes, often a dramatic improvement.
  2. Vertical scaling — a bigger machine (more CPU, RAM, faster disks). Simple, but has a hard ceiling and doesn't help with availability, exactly as covered generally in Scalability.
  3. Read replicas — if the workload is read-heavy (true of most applications), replication lets reads scale out across multiple followers while writes still go through one leader. This alone often buys a huge amount of headroom before anything more drastic is needed.
  4. Caching — pushing frequently-read data in front of the database entirely so it never has to answer the same query repeatedly. This gets its own full module (Caching Fundamentals); the short version here is that a cache reduces database load without changing the database's own architecture at all.
  5. Sharding — once write volume or dataset size exceeds what any single leader can handle, Database Sharding splits the data itself across multiple independent machines. This is the most powerful lever and also the most expensive to adopt — it changes how queries, joins, and transactions all have to be written.

Why the order matters​

Each step up this list trades more implementation and operational complexity for more headroom. Read replicas mean handling replication lag in application logic; caching means handling cache invalidation; sharding means giving up easy cross-shard joins and transactions. Reaching for sharding on day one — before indexes, vertical scaling, or read replicas have been tried — is usually solving a problem the system doesn't have yet, at a cost (schema complexity, operational overhead) it didn't need to pay yet either.

Reads vs. writes scale differently​

It's worth being explicit that "scaling the database" usually means two different problems wearing one name. Read scaling is comparatively easy — replicas and caches both work because reads don't need to agree with each other about ordering, they just need reasonably fresh data. Write scaling is the harder problem, because every write needs to be durably recorded exactly once and reconciled with every other write — which is why sharding (splitting the write path across machines) is the tool that specifically targets write scale, while replication mostly targets read scale.

Why this matters in an interview​

A strong answer to "how would you scale this database" walks through the ladder explicitly and says which rung the design actually needs, given the read/write ratio and data size described in the prompt — not just "we'd shard it." Naming read replicas as the first real scaling lever for a read-heavy workload, before jumping to sharding, is a concrete signal that you're reasoning about the actual bottleneck rather than reaching for the most impressive-sounding tool.

Read replicas before sharding: pros and cons​

Pros

  • Much lower implementation and operational complexity than sharding
  • No schema or query changes required — the database still looks like one logical unit
  • Directly addresses the common case: most applications are read-heavy

Cons

  • Does nothing for write throughput — all writes still go through one leader
  • Doesn't help once the dataset itself no longer fits on a single machine
  • Introduces replication lag that read-path application logic has to account for

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.