Query Cost Is a Product Decision

In most orgs, query cost is not something we bake into the design phase (mainly because we don’t know…duh). But it’s then subsequently forgotten all the way through the production and the first exciting invoice. Then people complain internally. Maybe we nudge the BI team about expensive dashboards. The BI team probably just ignores them, because the costs aren’t their costs, and the people who designed the queries that drove the bill aren’t the people seeing the bill. Six months later, an unexpected six-figure overrun lands on a finance review and everyone’s suddenly in deep shit.

The shape of the dashboard, the cadence of the refresh, the granularity of the data. These decisions determine the bill. The people making the decisions need to own the cost.

What Query Cost Depends On

And it’s not a single dimension to the cost. The factors that drive it are:

• Bytes scanned. The biggest single factor. A query that scans a partitioned subset of a table costs a fraction of one that scans the whole table.
• Compute size. The warehouse used to run it. Snowflake’s X-Small vs 4X-Large pricing differs by orders of magnitude.
• Query complexity. Joins, window functions, complex aggregations all cost more per row processed.
• Frequency. Hourly refresh vs daily refresh is a 24x cost difference.
• Concurrency. Two dashboards refreshing at the same time can spin up extra warehouses.
• Caching. A query that hits the result cache costs near-nothing. One that doesn’t pays the full price.

Of these, the ones a product designer controls are: bytes scanned (via filter design and partitioning), frequency (via refresh cadence), and concurrency (via scheduling). Three of the biggest cost drivers are product decisions, not infrastructure decisions. The dashboard’s cost is shaped at design time.

The 10x Dashboard

I’ve seen the same business question implemented two ways with a 10x cost difference. Both produce identical-looking dashboards. The expensive version:

• Refreshes every 15 minutes regardless of when data updates.
• Queries the underlying transaction-level table directly.
• Computes aggregations on every refresh.
• Loads all data, not just the displayed time window.
• Hits the database from a dozen widgets on the page, each with its own query.

The cheap version:

• Refreshes when the upstream pipeline signals new data (dbt State anyone?)
• Queries a pre-aggregated daily/hourly summary table.
• Loads only the displayed time window plus a small buffer.
• One query feeds the whole dashboard, sliced client-side.

It’s the same dashboard with the same answers. 10x cost difference. The decision lives at the BI tool level, with the dashboard designer.

The Agent Cost Problem

Analytics agents make this way worse. A dashboard’s queries are written once and known. An agent’s queries are written at run time, by an LLM, in response to user questions. The cost shape is harder to predict. Even with semantic models.

A single user question can trigger multiple tool calls, each running a query, each scanning some bytes. The user doesn’t see the cost. The agent doesn’t know the cost. The bill arrives at month-end and surprises everyone.

This is where the FinOps practice for agents starts to matter. Each agent interaction has a cost; that cost should be measured, reported, and ideally constrained per user or per session. Without this, agent costs can scale faster than agent value.

FinOps Maturity Curve for Data

What Helps?

The patterns that make cost a real input to product decisions:

1. Cost attribution per dashboard, per agent, per user. The bill gets broken down by who’s consuming it. The producer sees the consumption.
2. Cost budgets per business area. The team has a quarterly allowance. If they go over, they have a conversation with finance.
3. Cost showback to the designer. The BI tool shows the dashboard’s estimated monthly cost as you build it. Snowflake’s Query Insights and BigQuery’s INFORMATION_SCHEMA make this technically possible; the BI tools just need to surface it.
4. Cheap defaults. Dashboards default to daily refresh, materialised summaries, narrow time windows. You opt in to expense, not out of it.
5. Pre-flight cost estimation. Before a query runs, estimate the cost; warn if it’s above a threshold; require approval for expensive queries.
6. Reservation vs on-demand mix. Predictable workloads on reserved capacity; spiky workloads on-demand. The mix matters.
7. Use dbt state aware orchestrartion

The Shift

The underlying cultural change is that “the data team owns the bill” stops being a model that works at scale. The bill is too big and too distributed. The teams that own the cost have to be the teams that drive the cost, which means the BI designers, the analytics engineers, and increasingly the agent builders.

This is a familiar story. We went through it in the 2010s with cloud cost. The “infrastructure team owns the AWS bill” broke as soon as serverless and Kubernetes made every engineer a consumer of cloud spend. Data is going through the same evolution about ten years later, with the same lessons.

Query cost is a product decision. The people who make the decisions need the cost data to make them well. Until that happens, the bills will keep surprising people, and the surprises will keep getting bigger.