Shard design doesn't start from your tables

Neki’s shard-group design centers on query and transaction patterns rather than individual tables, aiming to co-locate related rows on a single Postgres shard so joins remain local and retain full transactional semantics. Shard groups use shard indexes, typically xxhash over a shared key such as customer_id, to distribute related customer, order, item, and address data across physical clusters, while allowing exceptions such as using a customers table’s id column. Reference tables such as countries or currencies can be replicated to every relevant shard to prevent cross-shard joins, and separate shard groups can organize differently related data, such as product catalogs by normalized SKU, while potentially sharing the same physical shards. The system also supports SQL expressions in shard keys, range and modulo indexing for compatibility with other placement models, and global secondary indexes that turn queries lacking a shard key into targeted lookup-and-read operations rather than broad fan-outs. Data placement can later be changed through MoveTables and Reshard workflows, enabling tables to be imported, redistributed, assigned new keys, or scaled to different shard counts as application workloads evolve.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.