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.
To see how far the same system goes, read PlanetScale's 118 million queries per second run on Neki, or compare shard-key choices in more horizontal sharding stories.
- Published
- 2026-10-23
- Scale
- 64-bit hashed keyspace split across shards, cross-shard transactions commit per shard, no atomic commit
- Techniques
- shard groups co-location reference tables global secondary indexes resharding
- Stack
- PostgreSQL Neki xxhash
Try this stack yourself
- Railway · Deploy something like this on Railway: spin up PostgreSQL plus your app in a few clicks. New accounts get $20 in credit (applied when you pick a paid plan).
Railway isn't part of PlanetScale's setup in this story. It's just an easy place to try the same building blocks.
Some links above are affiliate links: if you sign up, How They Scaled may earn a commission at no extra cost to you. We only list tools that fit the stack in the story.