$/TB scanned: a proxy for compute

Why does scan pricing make your bill a function of layout, and which metering clauses matter most?

Some query services bill per terabyte of data scanned. This is the strangest primitive because it is none of the four meters cleanly. It is a proxy for compute that the vendor can observe while sharing machines between many customers.

The consequence is severe: your bill becomes a function of physical layout and not of the question you asked. The same query costs different amounts on different days, as the table changes. Two queries with identical meaning differ in price because of the compaction state (how well small files have been merged) of the files underneath.

The proxy also has a systematic residual (a leftover error with a fixed direction, not random noise). IO-heavy work overpays and CPU-heavy work underpays. A cross join against a tiny table reads almost nothing but can burn a whole cluster, so it is nearly free to you. The gaming direction is predictable enough that vendors add governors (limits that stop expensive work, see Governors) to close the gap.

The practical correction: the rate is the least important part of scan pricing. Three questions change the cost of the same workload by up to 5× at an identical headline rate:

• does the meter count compressed or uncompressed bytes?
• does it apply a per-table or per-query minimum?
• does it charge before or after pruning?