Shard Key

When a single database server can no longer hold all your data or handle all your traffic, you split the data across many servers. Each server holds one slice, called a shard. The shard key is the piece of data the system looks at to decide which slice a given record belongs to.

For example, if you shard a users table by user_id, then user_id is your shard key. Every time you insert or look up a user, the database takes that user_id, runs it through a routing rule, and that rule points to exactly one shard. The record never lives on two shards, and a point query for one user only touches one shard.

A shard key is usually one column, but it can be a compound key made of several columns, such as (tenant_id, created_at). The key is chosen once at design time and is expensive to change later, because changing it means rewriting where every row lives.

There are two common ways to turn a shard key value into a shard. Range-based sharding sorts the key and assigns contiguous ranges to shards. For example user_ids 1 to 1,000,000 go to shard A, 1,000,001 to 2,000,000 go to shard B. This makes range scans efficient but tends to send all the newest inserts to the last shard.

Hash-based sharding runs the key through a hash function and uses the result to pick a shard. A hashed user_id scatters records across all shards evenly, which kills hot spots on writes, but it destroys ordering so range scans now have to touch every shard.

Many systems add a layer of consistent hashing or a lookup table so they can add or remove shards without rehashing every record. MongoDB keeps a config server that maps key ranges (chunks) to shards. Vitess and Citus keep similar routing metadata. The application usually does not pick the shard itself; a router or proxy reads the shard key off the query and forwards it.

The hard rule is that the shard key has to be present in the query for the router to find the data in one hop. A query that filters only on email when the shard key is user_id cannot be routed, so it fans out to every shard and waits for all of them. That scatter-gather query is slow and scales badly.

A good shard key has three properties. It has high cardinality, meaning many distinct values, so data can spread thinly. It has even distribution, so no single value gets a disproportionate share of rows or requests. And it matches your most common query so those queries hit a single shard.

Bad keys create hot spots. Sharding by country puts all of India or the United States on one node. Sharding by a monotonically increasing timestamp or auto-increment id sends every new write to the same shard, so one machine takes all the load while the rest sit idle. Sharding by a low-cardinality status field like active or inactive jams everything into two shards.

The painful trade-off is that one key cannot serve every access pattern. If you shard orders by customer_id, looking up an order by order_id becomes a scatter-gather. Teams handle this with secondary indexes, a global lookup table mapping order_id to shard, or by denormalizing data into a second sharded copy keyed differently. Pick the key that serves your hottest, highest-volume query, and accept that the rarer queries will be slower.

Imagine a multi-tenant SaaS analytics product where each customer (tenant) has millions of events. A natural shard key is tenant_id. Every dashboard query already filters by the logged-in tenant, so those queries route to exactly one shard, and a tenant's data stays physically together.

The risk is a whale tenant. If one customer is 100 times larger than the rest, its single tenant_id value lands all its data on one shard and overloads it while small tenants share another shard with room to spare. The fix is a compound shard key like (tenant_id, event_bucket) that splits a huge tenant across multiple shards while keeping small tenants intact.

This is exactly the kind of decision that is cheap to get right on day one and brutally expensive to fix once you have terabytes spread across the wrong key. That is why shard key selection is treated as an upfront architecture decision, not an implementation detail.