Principles — zero-copy, borrowed from systems programming.
Principles
The zero-copy discipline came out of high-frequency systems in C — ring buffers, cache-line alignment, release/acquire ordering. The vocabulary translates surprisingly cleanly to data platforms. This page is the translation.
The cheapest copy is the one that doesn't exist. Before extracting anything, ask whether a view, a federated query, or a direct read against the source will do. Most of the time it will — and the resulting stack has fewer moving parts, fewer schedules, and no drift by construction.
When a copy is genuinely required, put it at the seam where the data enters your world, under a schema you wrote on purpose. Everything downstream reads through that contract. No re-shaping in transit; no renames three joins deep. One boundary, one promise.
Borrowed from cache-line alignment: fields that are always read together belong in the same table, and fields that are written by different systems belong in different tables. Ignore this and you get contention — two teams stepping on each other's writes and one team's read blocked behind the other's compaction.
Long-running locks and full-table re-scans are how data platforms take their sources offline by accident. Prefer append-only change streams, CDC, and release/acquire-style publication: the producer commits, the consumer picks up the delta on its own clock. Nobody waits on anybody else's transaction.
The interesting metric is not warehouse credits or CPU minutes; it's how many times each row was copied on its way to a decision. Cut that number and cost, latency, and drift fall together. Chase hardware and you'll buy a bigger machine to run the same wasted copies faster.
Slowly changing dimensions are a copy-discipline problem in disguise. SCD Type 1 overwrites history — cheapest, lossy, fine for attributes nobody will ever ask about retroactively. Type 2 versions rows with valid-from / valid-to timestamps and a surrogate key; it's the honest default when the past matters, because it lets a fact join to the dimension as it was, not as it is. Type 3 keeps a prior-value column alongside the current one — a narrow compromise for one or two attributes that change occasionally and are always compared to their previous state. Pick per-attribute, not per-table. Most real dimensions are a mix.
Star schema keeps facts at a single grain surrounded by conformed dimensions read straight through: one join, no re-shaping, cache-friendly. Snowflake normalizes those dimensions into sub-tables to eliminate repetition and enforce hierarchy. Snowflake saves bytes; star saves hops. On modern columnar warehouses, hops usually cost more than bytes — start star, snowflake only where a dimension is genuinely large, deeply hierarchical, and shared across many facts.
Whichever you pick, write the grain down. A fact table without a stated grain is a table that will silently double-count within a quarter, and no amount of dashboard polish will surface it. Dimensional modeling is not decoration on top of a warehouse — it's the contract that keeps downstream reads honest without copying the source another five times to reconcile what the grain should have been in the first place.
Coda
If any of this resonates with a stack you're stuck inside, write to us. First conversation is 30 minutes and free.
hello@xerocopy.sh →