01
Sharding
Scale Postgres past the limits of a single machine to hundreds of millions of QPS and petabytes of data.
Now available
Neki is sharded Postgres by PlanetScale. Every shard is real Postgres. Neki adds the router, sidecars, and control plane to scale it past a single machine, to hundreds of millions of QPS and petabytes of data, without downtime.
[ NEKI ]
100M+
queriesper second
PB+
of dataper database
0
downtimeresharding
100%
realPostgres
Read the latest
We ran a massive, sharded Postgres database at 118.5 million queries per second, with 200k queries per second on each shard across 512 shards.
Sep 11, 2026 · Florent Poinsard
Read ↗Sep 10, 2026 · Nick Van Wiggeren
Sep 10, 2026 · PlanetScale
Sep 1, 2026 · Andres Taylor
Aug 24, 2026 · Josh Brown
Shard 01
Postgres
Shard 02
Postgres
Shard 03
Postgres
Shard 04
Splitting
01
Scale Postgres past the limits of a single machine to hundreds of millions of QPS and petabytes of data.
02
Split hot shards as workloads grow. Neki creates new target shards, catches them up with replication, and moves traffic through topology changes.
03
Move data to a new shard layout while the database stays online. Rebalance capacity without application rewrites or maintenance windows.
04
Each shard is real Postgres. Neki adds the router, sidecars, and control plane needed to scale Postgres horizontally.
05
Let the platform track health, promote replicas, and update routing. Applications keep using the same Postgres endpoint.
06
Run schema changes as coordinated workflows across shards. Neki applies the right method per shard and tracks progress through cutover.
07
Pool connections inside the sharded database layer. Neki routes with awareness of topology, shard health, and session state.
08
Assign different tables or workloads to different shard groups. Scale hot, cold, or isolated data on the hardware profile it needs.
09
Run each shard as a highly available Postgres cluster across availability zones. Failures stay isolated to the smallest possible unit.
10
Define how data maps to shards, shard groups, and shard indexes. Placement is explicit, reviewable, and built for controlled resharding.
11
Write across shards in one transaction. Neki coordinates commit so the change is atomic: every shard applies it, or none do.
12
Use explicit workflows for imports, resharding, schema changes, cutovers, and cleanup. Neki makes distributed Postgres operations repeatable.
13
Move to new Postgres versions through the same online migration model: create target shard groups, replicate, cut over, and retire the old groups.
14
Import into Neki while the source database keeps serving traffic. Copy, replicate, verify, and cut over when the target is ready.
15
Each Neki shard has its own WAL and logical replication path. CDC stays compatible with standard Postgres patterns and per-shard streams.
Start with a single shard and split as you grow. Bring an existing database over with a zero-downtime import, or talk to the team about your workload.