When Your Database Becomes the Bottleneck

Every successful application eventually faces the same challenge: the database becomes the bottleneck. You've scaled your application servers horizontally, added caching layers, optimized queries — but the database can't keep up. This is the moment when you need to understand database scaling patterns.

Database scaling is fundamentally more complex than application scaling because databases are stateful. You can't just spin up another instance and put it behind a load balancer. The data must be consistent, durable, and available. Every scaling decision involves trade-offs.

Read Replicas

The simplest database scaling pattern is read replication. Create copies of your database that receive all writes from the primary and serve read queries. Since most applications are read-heavy (often 90%+ reads), this can dramatically increase throughput.

read-replicas.txt

Plain Text

                    ┌─────────────┐
         Writes ──► │   Primary   │
                    └──────┬──────┘
                           │ Replication
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌─────────┐  ┌─────────┐  ┌─────────┐
        │ Replica │  │ Replica │  │ Replica │
        └────┬────┘  └────┬────┘  └────┬────┘
             │            │            │
             └────────────┼────────────┘
                          │
                       Reads

Sharding

When even a beefy primary database can't handle your write load, you need to distribute writes across multiple databases. Sharding (horizontal partitioning) splits your data across multiple database instances based on a sharding key.

Sharding Strategy	How It Works	Best For
Hash-based	Hash the shard key, mod by shard count	Even distribution, unpredictable access patterns
Range-based	Assign key ranges to shards	Range queries, time-series data
Directory-based	Lookup table maps keys to shards	Maximum flexibility, complex routing

Common Sharding Strategies

Sharding is Hard

Sharding adds significant complexity: cross-shard queries are expensive, joins become difficult or impossible, rebalancing shards requires careful planning. Don't shard until you've exhausted simpler options. Many applications never need to shard.

When to Use What

1First: Optimize queries, add indexes, tune the database. Often this is enough.
2Second: Add read replicas. This scales read capacity with minimal complexity.
3Third: Add caching (Redis, Memcached). Reduce database load for hot data.
4Fourth: Vertical scaling. Bigger machine, more RAM, faster SSDs.
5Fifth: Consider sharding only when writes are the bottleneck and vertical scaling hits limits.

“Premature sharding is the root of much evil in database architecture. I've seen teams spend months implementing sharding when read replicas would have solved their problem. Understand your actual bottleneck before choosing a solution.”
E
Elena Kowalski