Horizontal sharding for Postgres

Neki scales past a single primary while keeping one connection string. A router sits in front of real Postgres so applications keep talking to one database while data lives on one cluster or many. PlanetScale Postgres already helps with schema recommendations, Query Insights, and faster instances on Metal. Neki is the upgrade when you need more than one writer, schema changes that do not stall a large table, and backups that run per cluster instead of against one heap. You do not have to shard on day one. A new Neki database starts as one unsharded cluster and still runs the router, admin service, and sidecar: one connection string, failover, and pooling without a client-facing PgBouncer. When to shard depends on your traffic, access patterns, and data.

​

Why sharding matters

Horizontal sharding splits a logical table’s rows across multiple database instances, each with its own primary. A router sends each query to the shard or shards that hold the rows. That differs from vertical scaling, where you add CPU, memory, or faster disks to one server. A larger instance eventually hits a ceiling on write throughput and disk, and one failure takes the whole database with it. If read capacity is your bottleneck, replicas help, but you cannot add more write capacity to a single primary. Sharding is the next step when you need:

• More than one writer. Writes spread across shard primaries instead of one WAL.
• More storage than one instance can hold. Each shard has its own disk.
• A smaller blast radius. A lagged replica, a vacuum, or a restore is a shard problem, not a whole-database problem.
• Tenant isolation. A noisy customer can live on its own shard instead of starving the rest of the cluster.

​

When horizontal sharding makes sense

Multi-tenant SaaS often fits when a few tenants dominate storage or query volume. A tenant key can keep each tenant’s rows together and keep heavy tenants from starving others. Very large datasets or I/O-heavy workloads can exhaust one primary even after you tune queries and storage. Spreading rows across shards adds capacity that a larger instance does not. Write-heavy applications can scale reads with replicas, but every write still hits one primary. Sharding splits those writes. See When to shard for the full decision, including what partitioning does not solve.

​

Tune queries and Metal first

Neki is still in Platform Preview, and PlanetScale Postgres is still the best single-primary Postgres. Use Query Insights and schema recommendations before you split the database. Many limits are expensive queries or missing indexes, not a need for more primaries. Metal uses locally attached NVMe. Workloads that look like they need sharding are sometimes hitting I/O limits that Metal removes. Tune the workload and the storage class, then move to Neki when that one primary is still the limit. Neki is the next upgrade. You can import into an unsharded Neki database then add shards and split data later. See Neki vs PlanetScale Postgres and Migrate PostgreSQL to Neki.

​

Frequently asked questions

​

Need help?

Get help from the PlanetScale Support team, or join our Discord community to see how others are using PlanetScale.