Horizontal sharding: 6 real scaling case studies
6 of the 73 engineering write-ups in our database are tagged with the technique "horizontal sharding". They come from 5 companies (PlanetScale, Figma, Notion, Shopify and Slack) and were published between 2020 and 2026. Stack that shows up most often in these stories: MySQL (3), PostgreSQL (3), Vitess (3) and AWS RDS (2). Often combined with benchmarking (2), database migration (2) and online migration (2). 3 of the 6 state concrete scale numbers, for example "118.5M QPS sustained for 16 minutes" (PlanetScale). Each card below links to our short summary and the original post.
118 million queries per second on Neki
PlanetScale benchmarked Neki, its sharded Postgres, with single-shard primary-key point selects. Targeting about 200K QPS per shard, it went from 5 shards (about 1M QPS) to 50 (9.9M QPS, per-shard rate within 0.8%) to 512 shards and 480 routers, sustaining 118.5M QPS for 16 minutes over 1.22 PiB with a p99 of 6.06 ms at the router and about one error per 1.8 million queries. PlanetScale notes the run was read-only, primary-only with no replicas, and had no failover during the measured window.
How Figma's Databases Team Lived to Tell the Scale
Figma's nine-month effort to horizontally shard its Postgres stack using a custom query proxy and logical sharding before physical splits.
Horizontally scaling the Rails backend of Shop app with Vitess
Shopify's Shop app adopted Vitess to shard its Rails backend, covering keyspace design and the migration plan.
One million queries per second with MySQL
PlanetScale benchmarked a horizontally sharded Vitess cluster up to one million QPS.
Herding elephants: Lessons learned from sharding Postgres at Notion
Notion split its Postgres monolith into a fleet of logical shards keyed by workspace, using double-writes and backfills to migrate.
Scaling Datastores at Slack with Vitess
Slack's multi-year migration from active-active MySQL pairs to Vitess, so data could be sharded by any key, not only workspace.