Neki by PlanetScale

Sharded Postgres is here

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, the lucky cat］

NEKI

queriesper second

of dataper database

downtimeresharding

realPostgres

Read the latest

## Neki update: $50 Metal, read-only replicas, Azure, and more

Postgres compatibility, read-only replicas, smaller Metal instances, Azure, and more have landed for Neki since platform preview.

Oct 20, 2026 · Nick Van Wiggeren

Read ↗

1. ### Sequences and other volatiles in Neki

   Oct 14, 2026 · Mats Rydberg

2. ### Building a faster, lazier router for Postgres

   Oct 1, 2026 · Dirkjan Bussink

3. ### Handling hot shards

   Sep 28, 2026 · Simeon Griggs

4. ### When to choose x86-64 vs aarch64

   Sep 25, 2026 · Ahmed Darwich

All Neki posts ↗

Application

Shard 01

Shard 02

Shard 03

Shard 04

An application connects to the Neki router, which routes queries to Postgres shards. A fourth shard is being split online.

Sharding

Scale Postgres past the limits of a single machine to hundreds of millions of QPS and petabytes of data.

Shard splitting

Split hot shards as workloads grow. Neki creates new target shards, catches them up with replication, and moves traffic through topology changes.

Zero-downtime resharding

Move data to a new shard layout while the database stays online. Rebalance capacity without application rewrites or maintenance windows.

Real Postgres at scale

Each shard is real Postgres. Neki adds the router, sidecars, and control plane needed to scale Postgres horizontally.

05

High availability

Let the platform track health, promote replicas, and update routing. Applications keep using the same Postgres endpoint.

06

Online schema changes

Run schema changes as coordinated workflows across shards. Neki applies the right method per shard and tracks progress through cutover.

07

Connection pooling

Pool connections inside the sharded database layer. Neki routes with awareness of topology, shard health, and session state.

08

Shard groups

Assign different tables or workloads to different shard groups. Scale hot, cold, or isolated data on the hardware profile it needs.

09

Multi-AZ availability

Run each shard as a highly available Postgres cluster across availability zones. Failures stay isolated to the smallest possible unit.

10

Data topology

Define how data maps to shards, shard groups, and shard indexes. Placement is explicit, reviewable, and built for controlled resharding.

11

Cross-shard transactionsComing soon

Write across shards in one transaction. Neki coordinates commit so the change is atomic: every shard applies it, or none do.

12

Workflows

Use explicit workflows for imports, resharding, schema changes, cutovers, and cleanup. Neki makes distributed Postgres operations repeatable.

13

Online version upgrades

Move to new Postgres versions through the same online migration model: create target shard groups, replicate, cut over, and retire the old groups.

14

Zero-downtime imports

Import into Neki while the source database keeps serving traffic. Copy, replicate, verify, and cut over when the target is ready.

15

CDC

Each Neki shard has its own WAL and logical replication path. CDC stays compatible with standard Postgres patterns and per-shard streams.

Run Postgres at any scale.

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.