• Sources: primary, discussion
  • Summary: Nick Van Wiggeren states applications connect to a Neki router over the standard Postgres wire protocol, so existing drivers, ORMs and connection strings keep working, while the router carries a full Postgres parser and a distributed planner that decides which shards run a query and merges the results. Each shard is a full Postgres cluster with one primary and at least two replicas across three availability zones and no modified storage engine, a JSON data topology maps logical tables onto shards through shard indexes and shard groups, sidecars alongside each instance handle connection pooling, and schema changes, version upgrades, failovers, imports and resharding run as online workflows over the same connection. PlanetScale states Neki can run unsharded first, that this is a platform preview, that production workloads should not run on it, and that breaking changes are expected.
  • Why it matters: The design keeps the shard key visible and unmodified Postgres underneath, which is the tradeoff distributed Postgres-compatible databases usually take the other way.
  • Follow-up: Whether Neki reaches general availability, and what the router costs on queries that cross shards.

send feedback on this story