What Is Sharding?

What is sharding?

Sharding exists because vertical scaling has a ceiling. A single server can only hold so much data, accept so many writes, and serve so many concurrent connections. When a workload outgrows one machine, sharding spreads it across many machines, each responsible for a disjoint slice of the data. The approach was popularized by large web platforms in the 2000s and is now built into systems such as MongoDB, Vitess (MySQL), and Citus (PostgreSQL).

Sharding is distinct from two related techniques. Partitioning divides a table into segments that typically live within one database instance, mainly to speed up queries and simplify data lifecycle management (see partitioned tables). Replication copies the same data to multiple servers for redundancy and read scaling. Sharding differs from both: the data is split, not copied, and the pieces live on separate servers.

There are three main sharding strategies. Hash sharding applies a hash function to the shard key, distributing rows evenly but destroying range locality. Range sharding assigns contiguous key ranges to shards, which makes range scans efficient but risks hot spots when traffic concentrates in one range. Directory-based sharding uses a lookup service that maps keys to shards, offering flexible placement (including geographic placement) at the cost of an extra hop and a metadata service to operate.

How sharding works

Everything hinges on the shard key. The routing layer — a proxy, client library, or coordinator node — computes the owning shard from the key and forwards the query. A query that filters on the shard key touches one shard; a query that does not must be sent to every shard and merged, a pattern called scatter-gather.

-- shard key: user_id, 8 shards
-- shard = hash(user_id) % 8

-- Single-shard query: routed to exactly one server
SELECT * FROM orders WHERE user_id = 4271;

-- Cross-shard query: scatter-gather across all 8 shards
SELECT SUM(amount) FROM orders
WHERE placed_at > now() - interval '1 hour';

Production systems add refinements: consistent hashing or virtual nodes so that adding a shard moves only a fraction of the keys, automated rebalancing to migrate data without downtime, and distributed transaction protocols (such as two-phase commit) when a write must span shards. Cross-shard transactions are expensive, so schemas are usually designed so that related rows share a shard key.

Why sharding matters in real-time systems

Sharding solves write and storage scale, but it fragments the system's view of state. Each shard answers queries from its own local snapshot, and there is no single point where the whole dataset can be read at one consistent instant without extra coordination. Two queries hitting two shards may observe moments that are milliseconds apart — usually harmless, but relevant when an automated decision must reason over state that spans shards.

Derived state is the sharpest edge. An aggregate that crosses shard boundaries — a global spend total, a fleet-wide velocity count — requires either a scatter-gather read at decision time, which adds latency and can degrade under analytical load, or an asynchronously precomputed rollup, which lags the underlying writes. Systems that make sub-second decisions on cross-shard aggregates must account for one cost or the other.

Concurrency adds a final wrinkle: hash sharding balances load on average, but a hot key — one viral account, one heavily traded symbol — still lands on a single shard, concentrating contention exactly where traffic spikes.

FAQ