Resharding: 2 real scaling case studies
2 of the 94 engineering write-ups in our database are tagged with the technique "resharding". They come from 2 companies (Notion and PlanetScale) and were published between 2023 and 2026. Stack that shows up most often in these stories: PostgreSQL (2). 1 of the 2 state concrete scale numbers, for example "64-bit hashed keyspace split across shards" (PlanetScale). Each card below links to our short summary and the original post.
Shard design doesn't start from your tables
In Neki, PlanetScale's sharded Postgres, a shard group is the unit of co-location: tables in the same group that hash their shard key the same way (xxhash into a 64-bit keyspace split by key ranges) always land on the same shard. Sharding customers, orders, items and addresses by customer_id keeps single-customer queries and transactions on one shard, which matters because a transaction across two shards gets no atomic commit or shared snapshot. Lookup tables become reference tables copied to every shard, catalog tables get their own group keyed on lower(sku), range and modulo indexes support legacy schemes, and a global secondary index routes queries like orders by id without fanning out. Shard groups can be changed later with the Reshard workflow.
The Great Re-shard: adding Postgres capacity (again) with zero downtime
Notion tripled its Postgres fleet by re-sharding with logical replication and careful PgBouncer cutovers, with no downtime.