Data Stores

Sharding

Also known as: horizontal partitioning, data partitioning

Definition

Sharding splits a dataset across independent database instances by a partition key, so each shard holds a disjoint subset. It is the only way past a single machine's write and storage ceiling, and it costs you cross-shard joins, cross-shard transactions and global uniqueness.

Last reviewed · Part of the Architecture Glossary

In practice

Choosing the key is the entire decision, and it is very expensive to change later. The test: can the majority of your queries be answered from one shard?

StrategyGoodBad
Hash of entity IDEven distributionRange scans hit every shard
Tenant IDNatural isolation, single-shard queriesWhale tenants create a hot partition
GeographyData residency, local latencyUneven population, cross-region users
Time rangeTrivial archivalAll writes hit the newest shard

What you lose, and what replaces it:

  • Joins across shards → denormalise, or fan out and merge in the application.
  • Transactions across shards → a saga or two-phase commit.
  • Auto-increment IDs → UUIDv7 or Snowflake IDs.
  • SELECT count(*) → a maintained counter, or an approximation.

When it matters

Past roughly a single primary's write ceiling, or when one tenant's data must be physically isolated for compliance.

Common mistake

Sharding before exhausting the alternatives. Read replicas, connection pooling, partitioning within one instance, archiving cold rows and buying a bigger machine are all reversible; sharding is not. Modern hardware runs a single Postgres primary far further than most teams assume — see scaling to millions for where the real ceilings sit.

See also

Go deeper