Neki's Postgres sharding router forwards wire bytes and decodes only on demand
PlanetScale's Neki keeps PostgreSQL DataRow and Bind messages as raw protocol frames and only decodes what each query actually needs.
Why it matters · Every proxy, router or middleware that parses messages adds per-row cost. Neki shows how layering lazy, byte-backed representations takes most of that cost off the hot path, and which invariants you have to protect to keep it correct.
Neki sits between PostgreSQL clients and sharded PostgreSQL servers, so every query takes an extra network hop. Bussink argues that the router can't remove the hop, so it should avoid as much work as possible while the query passes through. The post walks through how Neki does this. It describes the design but includes no benchmark numbers.
Contrast with Vitess
Vitess, PlanetScale's MySQL sharding system, converts every protobuf result into [][]Value at each RPC boundary. MakeRowTrusted walks every column of every row, and on the way back RowToProto3Inplace walks the values twice. That gives the query engine one uniform type, but every result pays the conversion cost even when the router never reads a value. In Neki, the router-to-sidecar ExecuteResponse is mostly one raw byte field holding valid PostgreSQL response messages.
Lazy, composable layers
DataRows can exist in three forms, and Neki builds the next one only when a query needs it:
- Raw bytes: the router checks message headers and handles
CommandComplete, then forwards the bytes as they are. Point lookups and cross-shard scatter queries with no ordering or aggregation never build a row struct. Neki just merges the per-shardCommandCompletemessages. - Row slice:
LIMITneeds row boundaries. Neki counts DataRows to allocate the slice once, then creates wrappers that point into the original buffer.
