Neki Enables PlanetScale Postgres Sharding

Neki matters because it turns PlanetScale from a great MySQL specialist into a scale layer for whichever open source relational database a team already runs. Today, most managed Postgres products help with branching, autoscaling, or developer workflow, but they still keep one writeable database as the core unit. Neki extends PlanetScale’s proven Vitess playbook into Postgres, so very large apps can keep Postgres semantics while spreading writes and data across many machines instead of rebuilding around custom sharding or moving to Spanner.

• PlanetScale already has the operational muscle for this model on MySQL. Its current product is built on Vitess, the clustering system created to split MySQL workloads across shards transparently, so Neki is not a brand new go to market motion, it is the same hard scaling problem applied to Postgres.
  1 sacra 5 vitess
• That is different from the main Postgres challengers. Neon’s core architecture separates compute from storage and makes branches cheap, but its database still behaves like a single Postgres system for read write transactions. Supabase wins by bundling database, auth, and storage, not by offering native horizontal write scaling across shards.
  6 sacra 7 sacra
• The practical target is a narrow but valuable slice of workloads. Most apps never need sharding, but once a Postgres deployment outgrows one machine, teams usually end up stitching together app level routing, tenant based splits, or moving to Spanner, which uses a PostgreSQL interface on top of Spanner’s distributed engine rather than standard Postgres itself.
  3 planetscale 4 google 8 google

If Neki reaches broad production use, PlanetScale can become the default upgrade path for teams that start on ordinary Postgres and later hit scale limits. That would let it sit upstream of a much larger share of new application databases, while giving the market a rare option between hand built sharding and a full jump to a distributed database like Spanner.