Controlling Data Platform Costs: A FinOps Approach for Data Teams
On a consumption-priced platform, cost is the sum of thousands of small decisions made by people who never see the bill. Controlling it means showing each team what its work costs, giving it the means to act and judging spend against the value it produces. FinOps is the name for that practice.
The bill for a cloud data platform is hard to explain from the bill alone. The platform team can see which warehouses or projects ran. It cannot see, without further work, which team’s queries ran on them or what business purpose they served, and a forecast made without that knowledge is a guess.
Cloud data platforms made capacity elastic, and in doing so made cost a consequence of behaviour. A badly written query, a dashboard refreshing every few minutes for nobody, a full reload where an incremental one would do: each costs money, immediately, with no purchase order. This guide explains where the cost comes from, sets out the FinOps approach as it applies to data teams, and describes the levers available. It quotes no prices and promises no savings, because both depend entirely on the platform, the contract and the workload.
Where the cost comes from
Platform pricing varies in detail and shares a structure. Snowflake’s documentation states it for that product: “The total cost of using Snowflake is the aggregate of the cost of using data transfer, storage, and compute resources”1. The same three elements appear, under different names and rates, on other platforms.
Compute is the element that varies most with behaviour, and it is charged in one of two broad ways. Some platforms charge for the time processing capacity is running. Snowflake, for example, bills its virtual warehouses per second “with a 60-second minimum each time the warehouse starts”1. Others charge for the work done. Google’s BigQuery documentation describes both models side by side: “With on-demand billing, you pay for the number of bytes processed when you query or process your data. With capacity-based billing, you allocate processing capacity for workloads”2.
The model determines what drives the bill. Where time is charged, idle capacity left running is the waste. Where data scanned is charged, queries that read more than they need are the waste. A team has to know which applies before it can reduce anything.
Storage is the steadier element. It grows quietly, through retained history, duplicated tables and copies kept for recovery.
Data transfer is charged when data leaves a region or a provider. It becomes significant where data is moved repeatedly between platforms or clouds.
These are vendors’ descriptions of their own pricing, which changes. Current documentation and the organisation’s own contract are the authority for any calculation.
What FinOps is
The FinOps Foundation maintains the framework the discipline is named for. Its definition: “FinOps is an operational framework and cultural practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams”3.
Two things in that definition are easy to miss. The aim is value, and reducing spend is one means to it. And the method is collaboration between three groups who do not ordinarily share information: the engineers who cause the cost, the finance team that pays it and the business teams that benefit.
The framework states six principles4. Three bear most directly on data teams.
- “Everyone takes ownership for their technology usage”4. The framework elaborates: “Accountability of usage and cost is pushed to the edge, with engineers taking ownership of costs from architecture design to ongoing operations”4.
- “FinOps data should be accessible, timely, and accurate”4. People cannot own a cost they cannot see.
- “Business value drives technology decisions”4. Spend is judged against what it produces.
The framework also describes the work as three phases that repeat: “Inform, Optimize and Operate”5. They give this guide its structure.
The three FinOps phases applied to a data platform
| Phase | The question | For a data team this means |
|---|---|---|
| Inform | What are we spending, on what, and for whom? | Attribute compute and storage to teams, pipelines and products; show each team its own figures |
| Optimise | Where can we get the same value for less? | Fix expensive queries and schedules; match capacity to need; remove what is unused |
| Operate | How do we keep it that way? | Budgets, alerts, regular review and cost as part of design |
Where a data platform differs from general cloud cost management
FinOps was developed for cloud spending as a whole, and most writing about it concerns infrastructure: virtual machines, storage volumes, reserved capacity. A data platform shares the principles and differs in ways that change the practice. The differences are DII’s analysis, supported by the vendors’ own cost documentation.
- The unit of cost is the query. Infrastructure cost follows what is provisioned. Data platform cost follows what is run. Google’s cost guidance for BigQuery states the structure, “The primary costs in BigQuery are compute, used for query processing, and storage”6, and most of its advice is about individual queries.
- The people who cause the cost are often not engineers. An analyst exploring a table, or a dashboard on a refresh schedule, spends money. The same guidance is addressed to anyone who writes a query: “Before running queries, preview them to estimate costs”6. Cost awareness therefore has to reach analysts and report authors, which generic FinOps material aimed at engineering teams does not assume.
- Compute is shared. Many teams run work on the same warehouse or capacity, so cost cannot be read off a resource and has to be attributed from query history.
- Controls can stop work. Platforms offer limits that refuse a query or halt a user. BigQuery’s daily quota is described bluntly: “Users are not able to run queries once the quota is reached”6. A limit of that kind is a cost control and an availability risk at once.
The sections that follow apply the three phases with those differences in mind.
Inform: make cost visible and attributable
Nothing else works until cost can be attributed. The total bill tells a team that there is a problem. Only a breakdown shows where.
Attribute by owner. Every unit of compute should be traceable to a team and, ideally, to a pipeline or product. Platforms provide the means: separate warehouses or projects per team, tags and labels on workloads, and query history that records who ran what. The discipline is to apply them consistently, so that the unattributed remainder is small.
Decide how shared costs are split. Some costs serve everyone: the ingestion of core data, the shared models. Agree a rule for allocating them. A simple rule consistently applied is better than a precise one that is disputed.
Show the figures to the people who cause them. A cost report that goes only to the platform lead changes nothing. Each team should see its own spend, its trend and its most expensive workloads, as soon as the data is available.
Choose showback or chargeback. Showback reports each team’s cost without billing it. Chargeback moves the cost to the team’s budget. Showback is the right place to start. It creates awareness without the internal accounting, and without the argument about allocation rules that chargeback provokes when the data is still imperfect.
Relate cost to something meaningful. The FinOps principles observe that “Unit economic and value-based metrics demonstrate business impact better than just aggregate or categorized technology spend”4. For a data team, useful units are cost per pipeline run, per report, per active user or per data product. A rising total may be healthy if the cost per unit is falling.
Optimise: the levers a data team has
The framework distinguishes two kinds of optimisation and who is involved in each: “Usage optimization requires collaboration with engineering teams primarily, while rate optimization options require collaboration with procurement and leadership”5. Data teams control the first directly.
Usage: what engineers can change
- Fix the most expensive workloads first. Rank queries and pipelines by cost and examine the top of the list. A single inefficient job can be worth more attention than a hundred small ones.
- Process incrementally. Rebuilding a full table each run when only new records have changed is a plain source of avoidable compute. The choice interacts with how transformation is organised, discussed in ETL vs ELT: how to choose for your workloads.
- Match the schedule to the need. A pipeline that runs hourly to feed a report read once a day runs twenty-three times for nothing. Ask each consumer how fresh the data has to be.
- Stop idle capacity. Where time is charged, configure capacity to suspend when unused and size it to the workload.
- Read less. Where data scanned is charged, partitioning, clustering and selecting only the needed columns reduce what each query touches.
- Remove what nobody uses. Tables no one queries and dashboards no one opens still cost storage and scheduled compute. Retiring them is the subject of rationalising a sprawling BI estate.
- Set retention deliberately. Keep history for as long as there is a reason, and move older data to cheaper storage tiers where the platform offers them.
Rate: what is negotiated
Rate optimisation concerns what is paid per unit: committed-use discounts, capacity reservations and the choice of pricing model. On this the documentation is worth reading closely. Google notes of its two models, for example, that “You can switch between on-demand and capacity-based billing models at any time”2. Commitments lower the unit price in exchange for a promise to spend, and are only as good as the forecast behind them. They should follow visibility, since a commitment made before usage is understood can lock in waste.
Operate: make it routine
Savings from a one-off clean-up erode unless cost becomes part of how the team works.
Budgets and alerts. Give each team a budget and alert when spend departs from the expected pattern. An anomaly caught in a day costs a day. One caught on the monthly invoice costs a month. Platforms also offer hard limits that stop workloads at a threshold. Use them with care, on development and exploratory work, since a limit that halts a production pipeline creates an incident.
A regular review. A short monthly meeting of the platform team, the main consuming teams and finance, looking at trend, anomalies, the top workloads and progress on actions. This is the collaboration the framework calls for, in its simplest form.
Cost in design. A new pipeline or data product should come with an estimate of what it will cost to run, and that estimate should be checked after launch. The cheapest time to fix an expensive design is before it is built.
Guard rails by default. Timeouts on queries, default auto-suspend settings and sensible limits for new users prevent the accidental large bill without requiring anyone to be careful.
Mistakes to avoid
Four errors are worth guarding against. They are DII’s cautions.
Treating it as a cost-cutting project. A drive to cut spend by a target figure produces a one-time reduction and resentment. The purpose is value. Some workloads should cost more, because what they deliver justifies it.
Centralising all control. A platform team that polices every query becomes a bottleneck and takes on a responsibility it cannot discharge. The principle is ownership at the edge, with the centre providing visibility, tooling and negotiated rates. The FinOps principles put the central role precisely: “FinOps should be enabled centrally”4.
Optimising before measuring. Effort spent tuning workloads that turn out to be a small part of the bill is wasted. Attribute first.
Ignoring the cost of people. An engineer’s week spent saving a small monthly sum is a poor trade. Optimisation has a cost of its own and should be directed where the return is clear.
Cost and the rest of the platform
Cost is one of the things a platform has to be operated for, alongside reliability and security, as set out in what a modern data platform is. Two moments make it especially visible. During a move between platforms, the organisation pays for both, and the migration plan should say for how long; planning a data platform migration covers that. And when a platform is run as a service to internal teams, the funding model determines who sees the cost and who is motivated to manage it, which is discussed in running a data platform as a product.
The Data Platform Cost / FinOps Tracker provides a structure for the Inform phase: cost by team and workload, unit measures, budgets and a log of optimisation actions with their results.
Sources
- Snowflake. Understanding overall cost (Snowflake documentation).
- Google Cloud. Introduction to workload management (BigQuery documentation). Updated 7 October 2026.
- FinOps Foundation. FinOps Framework Overview.
- FinOps Foundation. FinOps Principles.
- FinOps Foundation. FinOps Phases.
- Google Cloud. Estimate and control costs (BigQuery documentation). Updated 7 October 2026.
This article is general professional information. It is not legal or regulatory advice.