dbt materialization cost: view, table, incremental, and what each one bills

Quick answer

A dbt model materialized as a view costs nothing to build and full price every time it is queried. As a table it costs a full rebuild on every run and is cheap to query. As incremental it processes only new or changed rows, which on a large append only table cuts build cost by 95 percent or more. A 500 GB fact table rebuilt hourly costs roughly $18,000 a month in scan charges at $5 per TB; the same model incremental, processing 2 GB an hour, costs about $72. Choose by build frequency times model size versus query frequency times query size.

Analytics engineers pick materializations by convention: views for staging, tables for marts, incremental when something gets slow. That convention is mostly right, but nobody attaches numbers to it, so the expensive cases survive for months. The materialization strategy is a cost allocation decision. It determines whether you pay once per build or once per query, and at what size.

What each one charges for

Materialization	Build cost	Query cost	Storage
view	Near zero	Full underlying scan every time	None
table	Full scan and write each run	Scan of the result only	Full copy
incremental	New and changed rows only	Scan of the result only	Full copy
ephemeral	None, inlined as CTE	Inherited by the consuming model	None
materialized view	Continuous maintenance charge	Very low	Full copy

The crucial asymmetry is that views push cost onto consumers and tables absorb it at build time. A staging view queried by 12 downstream models is scanned 12 times per run. If it sits on a 300 GB source, that is 3.6 TB per run, $18 at $5 per TB, against a one off $1.50 to materialize it as a table that the 12 models then read cheaply.

The incremental case, with numbers

Take a fact table of 500 GB holding two years of events, rebuilt on a schedule.

Strategy	Runs/day	Data processed/run	Monthly scan cost at $5/TB
Full table rebuild, hourly	24	500 GB	~$1,800
Full table rebuild, daily	1	500 GB	~$75
Incremental, hourly	24	~2 GB	~$7.20
Incremental, hourly, with monthly full refresh	24	~2 GB plus 1 rebuild	~$9.70

Hourly freshness costs $1,800 a month as a full rebuild and under $10 as an incremental. The incremental model needs a reliable filter on the source, typically a loaded at or updated at timestamp, and a unique key for merge behaviour, but the engineering effort is an hour and the payback is immediate. This is far and away the highest value change available in a typical dbt project.

Incremental strategies and their cost

Strategy	How it writes	Cost profile
append	Insert only	Cheapest, no read of target
merge	Match on unique key, update or insert	Reads target partitions, moderate
delete+insert	Delete matching keys, insert new	Similar to merge, sometimes cheaper
insert_overwrite	Replace whole partitions	Cheap if partitions are narrow

The trap with merge is that a naive merge can scan the entire target table to find matching keys. Adding a predicate that limits the merge to recent partitions, for instance restricting the match to the last 3 days, turns a 500 GB target read into a 4 GB one. On an hourly model that single clause is worth roughly $1,780 a month. Where the source is strictly append only, use the append strategy and skip target reads entirely.

When views are correct

Views are right for light transformations on small sources, for models queried rarely, and anywhere you need guaranteed freshness with no build step. They are wrong for anything expensive that many things read. The test is simple: multiply the underlying scan size by the number of times the view is queried per day, and compare against the cost of building it once. If the view is read more than a handful of times, materialize it.

Ephemeral models are worth noting because they look free and are not. An ephemeral model is inlined as a CTE into every consumer, so its logic runs once per consumer. Four consumers means the work happens four times. For anything non trivial, a table is cheaper.

Run scheduling is half the bill

Building every model on every run is the other common waste. If 200 models run hourly but only 15 have sources that update more than daily, you are paying 24 times over for 185 models. Split the project into schedules by freshness requirement: hourly for the genuinely real time subset, daily for the rest, weekly for slowly changing dimensions. Use selectors and tags so this is explicit rather than accidental. Teams commonly cut total build cost by 60 to 80 percent with scheduling alone, before touching a single materialization.

Also check warehouse sizing per job: heavy full refreshes benefit from a largerwarehouse sized for the work, while small hourly incrementals should run on the smallest warehouse that fits. The orchestration compute, whether containers, functions, or a managed scheduler, is Terraform, and C3X prices it from theresource catalog alongside everything else.

FAQ

Which dbt materialization is cheapest?

It depends on the ratio of builds to queries. Views cost nothing to build but pay a full underlying scan on every query, so they are cheapest for rarely queried models. Tables and incremental models pay at build time and are cheap to query. Incremental is almost always cheapest for large, frequently rebuilt fact tables.

How much does an incremental model save?

Typically 95 percent or more on large tables. A 500 GB fact table rebuilt hourly costs roughly $1,800 a month in scan charges at $5 per TB, while the same model built incrementally processing about 2 GB per run costs around $7.20. The change requires a reliable timestamp filter and a unique key, roughly an hour of work.

Why is my dbt merge strategy still expensive?

A naive merge scans the entire target table looking for matching unique keys. Adding an incremental predicate that restricts the match to recent partitions, for example the last three days, turns a 500 GB target read into a few GB. On an hourly model that single clause can be worth well over $1,500 a month.

Are ephemeral models free?

No. An ephemeral model is inlined as a CTE into each consuming model, so its logic executes once per consumer. Four downstream models means the work runs four times. For trivial column renaming that is fine, but for anything involving joins or aggregation a materialized table is usually cheaper despite the storage.

Should every dbt model run on the same schedule?

No, and this is often the largest saving available. If 200 models run hourly but only 15 have sources updating more than daily, you pay 24 times over for 185 of them. Splitting the project into hourly, daily, and weekly schedules by actual freshness requirement commonly cuts total build cost by 60 to 80 percent.

How does C3X fit into a dbt project's cost?

C3X prices the Terraform managed infrastructure around the project: the orchestration compute running your schedules, the storage holding source and target data, and the network paths between them. Those resources scale with how often and how heavily models run, and C3X surfaces their cost in the pull request rather than on the invoice.

What to do next

Cost the infrastructure behind your pipelines. C3X prices your Terraform resources at review time. Start with the quickstart.