Sharding
Splitting one table's rows across several databases so no single machine has to hold or write the whole dataset.
See it
What it is
Sharding splits a dataset horizontally: each database holds some rows with the same schema, and a shard key decides where a row lives. Customer 1 might land on shard A while customer 2 lands on shard B. Unlike a read replica, every shard owns a different slice and accepts writes for that slice. MongoDB, Citus, and Vitess, which YouTube built to shard MySQL, can manage this routing for you.
Reach for it when one database can no longer fit the data, write rate, or working set you need even after indexing and vertical scaling. A good shard key appears in common queries, spreads load evenly, and keeps data that is queried together on the same shard. Tenant ID is often useful in business software; a timestamp alone often creates one hot shard.
Gotcha: the split leaks into everything. Cross-shard joins, unique constraints, transactions, backups, and schema migrations all become coordination problems. A large customer can still create a hot shard, and changing the shard key later means moving live data. Shard after measurement, leave headroom for rebalancing, and make the routing rule a first-class part of the data model.
Ask AI for it
Shard this multi-tenant PostgreSQL schema with Citus. Use tenant_id as the distribution column, add it to every tenant-owned table and every primary or unique key, then call create_distributed_table for those tables with colocate_with so related tenant rows share a shard. Keep small shared lookup tables as Citus reference tables. Rewrite queries and foreign keys so tenant_id is always present, identify every cross-shard join or transaction, and include a migration plan that backfills tenant_id, validates row counts, cuts traffic over, and can roll back safely.