A grocery marketplace of Instacart's kind lands 600 retailer inventory feeds into the warehouse raw and transforms them on read with layered views. What has the team gained, what are they paying, and when does the bill arrive?

What is gained, and it is real

• A transformation bug is fixable without re-ingesting. The raw feed is still there, so a wrong currency conversion discovered in March can be corrected for January by changing a view. Under transform-on-write, that data is gone and the supplier may not be able to resend it.
• Definition changes do not need a pipeline deploy. A new "in stock" rule ships as SQL.
• Six hundred feeds with six hundred shapes do not have to agree up front. Schema-on-read absorbs a partner who renames a column, and the breakage surfaces in one view rather than stopping ingestion.

What is paid

• Every reader pays the transform, every time. A view stack six levels deep is re-executed on each query, so the cost moves from a predictable nightly job to unpredictable ad-hoc demand.
• Bytes scanned multiply. A query filtering on a derived column cannot prune partitions by it, so a selective-looking query reads the raw table in full.
• Nobody can reason about the lineage. Six layers of views with overlapping names is the warehouse equivalent of deep inheritance, and the failure mode is a definition that two teams believe means different things.
• Freshness becomes invisible. With a pipeline, "last run at 04:12" is a fact. With a view, freshness is whatever the underlying feeds happen to have landed.

When the bill arrives

At popularity, not at launch. The pattern is cheap while a dashboard has five users and the feeds are small. Two things change it: a dashboard that becomes part of a daily routine for 300 people, and a feed whose volume grows tenfold. Both multiply bytes scanned against a price charged per terabyte scanned - low single-digit dollars per terabyte at the major warehouses' 2026 list prices - so a query that cost cents becomes a line item someone in finance asks about.

The second bill is latency. A view stack that took 4 seconds at 50 GB takes 40 at 500 GB, and the dashboard that was pleasant becomes one people avoid.

The decision rule

Materialise where the read-to-write ratio is high and the definition is stable; transform on read where the shape is still moving or the data is rarely queried. Concretely: a model read more than a few dozen times a day whose definition has not changed in a month should be a table, refreshed incrementally.

Keep the reversal cheap by defining each model in exactly one place and letting materialisation be a property of that definition rather than a rewrite. That is the real argument for a transformation framework over hand-written views: not elegance, but that switching a model from view to table stays a one-line change.

When this is the wrong answer

For a pipeline feeding a regulated report, transform-on-read is the wrong default outright: you need a dated, immutable artefact that can be reproduced exactly, and a view that re-derives from whatever the raw tables contain today cannot give you that. Land raw, transform to a versioned table, and keep both.