Query-Level Economics: Who Runs What, at What Cost, and for What Return

The $4,000 SELECT Statement

A data engineer at a mid-sized SaaS company once ran a query on a Friday afternoon and went home for the weekend. She had joined two fact tables, forgotten a partition filter, and kicked off a full scan across three years of event data sitting in a columnar warehouse. The query ran. It finished sometime Saturday morning. It cost the company just over four thousand dollars.

Nobody yelled at her. Nobody could. The warehouse bill arrived the following month as a single line item, the query got buried inside a cluster of 180,000 other queries from that billing period, and the only person who noticed the spike was the finance controller, who assumed it was a vendor price change. The engineer is still there. The query pattern is still in production. It runs every Friday.

This is the FinOps problem nobody talks about at conferences. Compute costs do not come from infrastructure. They come from decisions. And the smallest, most ignored, most replicated decision in any data organization is the query.

The Turn

Most FinOps programs operate at the altitude of a cruise ship captain. They see the big weather systems. Reserved instances versus on-demand. Warehouse sizing. Storage tiering. Commitment discounts. These matter. They are also the part of the bill that gets the least interesting over time, because once you make the decision, the decision makes itself forever.

Queries are different. Queries are a live, breathing, constantly-mutating population of tiny economic events, each one authored by a human (or, increasingly, a dashboard, a reverse ETL job, or a poorly-trained model) with no incentive to care what it costs. Every query is someone spending someone else's money to answer a question that may or may not matter.

Query-level economics is the discipline of putting a price tag on each of those questions and figuring out whether the answer was worth it.

Why Queries Escape Finance

There is a reason this blind spot exists, and it is not negligence. It is architecture.

Cloud data warehouses were built to make queries cheap to start. BigQuery will accept anything you throw at it. Snowflake will spin up a warehouse in seconds. Databricks will auto-scale your cluster to meet demand. The friction that used to exist between an analyst and a full table scan, the DBA who would have looked at your query plan and told you to go away, has been optimized out of the system. That is the product. That is what the customer is paying for.

The result is a cost model where the marginal cost of one more query is approximately zero to the person running it, and the aggregate cost is approximately everything to the person paying the bill. Economists have a name for this. It is the tragedy of the commons, and every Snowflake account over $500K in annual spend is a working demonstration of it.

The first job of query-level FinOps is not to reduce costs. It is to reintroduce friction. Specifically, informational friction. You cannot ask a thousand analysts to be frugal if you have never told a single one of them what a query costs.

The Three Questions

A mature query-level FinOps practice answers three questions for every dollar the warehouse spends. Think of them as concentric rings. You cannot answer the outer ones until you have answered the inner ones.

Question One: Who Runs What

This sounds like a solved problem. It is not. Every major warehouse exposes a query history table of some kind. Snowflake has QUERY_HISTORY. BigQuery has INFORMATION_SCHEMA.JOBS. Redshift has STL_QUERY. Databricks has query profiles in the system tables. In theory you can query the query log and find out who ran what.

In practice, the user running the query is almost never the human who caused it to run. The user is a service account named tableau_prod or looker_worker_07 or, more commonly, dbt_transformer, which is a robot running code that some engineer wrote six months ago and forgot about. The query log will tell you that dbt_transformer spent $87,000 last month. It will not tell you which model inside dbt caused the spend, which pull request introduced that model, or which business stakeholder asked for the dashboard that depends on it.

The foundational work of query-level economics is building an attribution graph. Every query needs a lineage that traces back to a human-readable owner and a human-readable purpose. At minimum:

Query ID → Execution context (dbt model, Looker dashboard, Airflow DAG, ad-hoc notebook) → Code location (git repo, file, line) → Owner (person or team) → Stakeholder (who asked for this) → Business purpose (why does it exist)

Most organizations can get the first three. The last two are where the real work lives, and they are also where the savings live. A query with no identifiable stakeholder is, by definition, a query that can be turned off without anyone complaining. You would be astonished how many of those exist in a typical warehouse. In one engagement I saw, 22% of recurring compute spend traced to dashboards that had not been opened by a human in over ninety days.

Question Two: At What Cost

Cost attribution is harder than it looks because warehouse pricing is not really pay-per-query. It is pay-per-resource-consumed, and resources are shared. If three queries run on the same Snowflake warehouse at the same time, what does each one cost? The honest answer is that there is no single correct number. There are only allocation schemes, and each scheme embeds a political choice about who gets blamed for idle time.

The three dominant schemes are worth knowing by name:

Time-weighted allocation divides the warehouse cost across queries based on how long each one ran. Simple. Also unfair, because a query that runs for ten seconds on an idle warehouse gets billed for ten seconds of a fully-provisioned cluster, while a query that runs for ten seconds during a spike gets billed the same. Idle cost disappears into nobody's budget, which means it ends up on the platform team's budget, which means the platform team looks bad for reasons they cannot control.

Resource-weighted allocation tries to estimate the actual CPU, memory, and IO each query consumed and bills proportionally. More fair, much harder. Snowflake does not give you perfect resource accounting per query. BigQuery's slot-millisecond model is closer, but slots are themselves a fiction that abstracts over real hardware. Anyone who tells you their resource-weighted allocation is accurate to the penny is selling something.

Hybrid allocation splits warehouse cost into a fixed overhead bucket (allocated across teams via some agreed-upon formula, usually based on share of total queries) and a variable bucket (allocated per-query based on resource consumption). This is what most mature practices converge on. It is not accurate. It is defensible, which is a different and more useful property.

The point is not to find the one true cost of a query. It is to pick an allocation scheme your organization will stop arguing about so you can get back to the actual work of using the numbers.

Question Three: For What Return

This is the question that separates FinOps from cost-cutting.

A query that costs $4,000 and informs a pricing decision that generates $400,000 in margin is the best query you ran all year. A query that costs forty cents and runs every fifteen minutes to refresh a dashboard that nobody looks at is a slow, quiet catastrophe. Raw cost tells you neither. You need a denominator.

The denominator is the hardest part of query-level economics, and it is where most FinOps programs quietly give up. Measuring cost is a data engineering problem. Measuring return is an organizational problem, which is to say, it requires talking to people. Specifically, it requires each query or class of queries to be tagged with something like a value hypothesis. "This dashboard exists because the revenue team uses it to decide which accounts to prioritize." "This model feeds the fraud detection pipeline, which prevented $2.3M in chargebacks last year." "This ad-hoc query was part of a one-time investigation into churn."

You do not need perfect value measurement. You need value measurement that is better than zero, which is the current state. Even a crude tier system, high-value / medium-value / unknown-value / known-waste, will force conversations that surface enormous savings. The unknown-value tier is the gold mine. Every query in that bucket is a query whose owner could not, when asked, explain why it exists. Most of them can be killed. The rest become high-value or known-waste once someone actually thinks about them, and either outcome is better than the status quo.

The Cletrics Framework, or Whatever You Want to Call It

Once you have the three questions answered, you can build what I think of as a query economics ledger. Not a dashboard, a ledger. The distinction matters. A dashboard shows you cost trends. A ledger assigns every unit of cost to a name and a purpose, the way double-entry bookkeeping assigns every transaction to an account. If you cannot point at a dollar of warehouse spend and name the human who authorized it and the business outcome it was meant to produce, that dollar is not being managed. It is just being spent.

The ledger has four columns:

The query, or more usefully, the query pattern (a normalized fingerprint that groups all executions of the same logical query together, even across parameter changes).
The owner, resolved through the attribution graph to a specific human or team, not a service account.
The cost, allocated via whatever scheme your organization has agreed to stop arguing about.
The return, expressed as a value tier plus, where possible, a short sentence about the business outcome the query supports.

Build this ledger and something strange happens. The conversation about cloud costs stops being a conversation about cloud costs. It becomes a conversation about which questions your business is paying to answer, and whether those are the right questions. The CFO stops asking why the Snowflake bill went up. The CFO starts asking why the company is spending $80,000 a month computing metrics for a product line that was sunsetted in March. Those are much better conversations.

The Uncomfortable Part

Query-level economics, done honestly, will embarrass some people. The senior analyst whose "critical" dashboard turns out to be a dashboard nobody reads. The engineer whose nightly batch job costs more than the salary of the person it was built for. The executive whose pet project consumes 8% of data platform spend for reasons that evaporate under scrutiny. This is a feature of the practice, not a bug. Most of the savings in a mature FinOps program come from things the organization was already slightly ashamed of and had agreed, tacitly, not to look at.

If your FinOps work is not occasionally making people uncomfortable, it is probably not working. You are measuring costs everyone already knew about and proposing optimizations everyone already agreed to. That is the easy 10%. The real 30% is in the queries nobody wants to talk about, and the only way to get there is to build the ledger, publish it, and let the data make the case you cannot.

Landing

The engineer who ran the $4,000 query on Friday afternoon is not the villain of this story. She is the protagonist. She did exactly what the system she worked in had trained her to do, which was to answer questions quickly without thinking about what the answer cost. The system failed her. It never showed her the price tag. It never gave her a reason to ask whether the question was worth asking.

Query-level economics is the work of putting the price tag back on. Not to punish the people running the queries, but to give them the information they have been missing, which is that every question they ask the warehouse is a transaction, and every transaction has a counterparty, and the counterparty is the business. When analysts know what their queries cost, they start asking better questions. When engineers see their models in a ledger next to a business outcome, they start building better models. When executives see a column labeled "return" next to one labeled "cost," they start making better calls.

That is the whole game. Not cheaper queries. Better questions.

Chapter in a Sentence Query-level FinOps is the practice of answering, for every dollar your warehouse spends, who ran what, at what allocated cost, and for what measurable business return, and building a ledger that makes those three answers impossible to ignore.