PATTERN Cited by 1 source
Reference-table materialization via VReplication¶
Pattern¶
Push a small, read-mostly lookup table out to every shard via a continuous-replication materialize workflow, so joins between the lookup table and the sharded data execute locally on each shard in parallel. This replaces the alternatives of (a) keeping the lookup table in an unsharded keyspace and fanning out joins, or (b) folding the lookup data into every row of the sharded table as denormalised columns. The mechanism is a VReplication Materialize workflow that treats the lookup keyspace as source and every target shard as a replication sink; changes to the lookup table stream continuously to every shard, keeping copies consistent.
Trade: write amplification × shard-count for the reference table (and the storage cost × shard-count on every shard), in exchange for shard-local join semantics on every query that touches the reference table. Works when the lookup table is small (bounded by the largest shard's storage budget), low-write-rate (so the per-shard amplification doesn't stress the replication stream), and frequently joined (so the shard-local-join win is paid out often).
Vitess 21 canonical instance: Materialize command gains explicit reference-table support, simplifying the previously hand-authored workflow.
Seen in¶
- sources/2026-04-21-planetscale-announcing-vitess-21 — Vitess 21 ships explicit
Materialize-command support for reference tables: "Such tables might be used to hold lists of countries, states, zip codes, etc., which are commonly used in joins with other tables in the sharded keyspace. Using reference tables allows Vitess to execute joins in parallel on each shard, thus avoiding cross-shard joins." Canonical wiki instance of the pattern, materialised as a first-class VReplication primitive rather than a hand-authored workflow.