Databases at Scale

The database is the beating heart of most applications, and it is usually the first component to buckle under load. Scaling a database is harder than scaling stateless application servers because data has gravity: it is heavy to move, expensive to duplicate, and sensitive to consistency semantics.

This guide covers the techniques used to scale relational and non-relational databases: replication for availability and read throughput, sharding for write throughput, indexing for query speed, partitioning for manageability, and the CAP theorem tradeoffs that shape every distributed datastore.

By the end, you should be able to reason about when to add replicas, when to shard, when to denormalize, and when to trade strong consistency for availability.

Replication copies data from a primary node to one or more replica nodes. It improves availability — if the primary fails, a replica can be promoted — and read throughput — read queries can be distributed across replicas. The cost is complexity: replicas lag behind the primary, and failover must be handled carefully to avoid split-brain.

Synchronous vs Asynchronous Replication

In synchronous replication, the primary waits for at least one replica to acknowledge a write before committing it to the client. This guarantees durability but increases write latency. In asynchronous replication, the primary acknowledges immediately and replicates in the background. It is faster but risks data loss if the primary fails before replication completes.

Sharding partitions data across multiple independent database instances. Each shard contains a subset of the data and handles its own reads and writes. When a single node cannot handle the write volume or dataset size, sharding allows the cluster to scale horizontally.

Shard Key Selection

The shard key determines how data is distributed. A poor choice creates hot shards, where one node receives disproportionate traffic. A good shard key has high cardinality, even distribution, and aligns with query patterns.

Indexes are data structures that speed up reads at the cost of slower writes and additional storage. Without an index, a database scans every row to answer a query. With the right index, the same query touches only a handful of pages.

B-Trees

B-trees are the default index type in most relational databases. They keep data sorted and balanced, allowing logarithmic-time lookups, range scans, and ordered iteration. B-trees work well for equality and range queries on stable, ordered keys.

Hash Indexes

Hash indexes map keys directly to disk locations using a hash function. They provide O(1) equality lookups but cannot support range queries or ordering. They are common in key-value stores like Redis and DynamoDB partition keys.

Partitioning splits a single logical table into smaller physical chunks within the same database. Unlike sharding, partitioning is usually transparent to the application. It improves query performance and maintenance — old partitions can be archived or dropped cheaply.

The CAP theorem states that a distributed data store cannot simultaneously provide Consistency, Availability, and Partition tolerance. In practice, network partitions are unavoidable, so the real choice is between consistency and availability during a partition.

Read replicas are the lowest-friction way to scale read-heavy workloads. They are asynchronous copies of the primary database that accept read traffic. The pattern is simple: writes go to the primary; reads go to replicas, with critical reads optionally forced to the primary.

There is no best database. The right choice depends on data shape, access patterns, consistency needs, and operational expertise. Modern architectures often use multiple databases — a pattern called polyglot persistence.