Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Engineering FinOps, the practice of treating cloud cost as an engineering concern rather than a finance one, has had ten years to mature for general software. Data FinOps is about five years behind that. Data teams are mostly where software engineering teams were in 2018: aware that the bill is too high, vague on what’s driving it, blaming the cloud provider, no real practice in place. The path from there to maturity isn’t a mystery; the software industry walked it. Worth laying out as a curve, because most data teams are somewhere on it without knowing.
Stage 0: ignorance
The bill arrives once a month. Someone in finance complains. Someone in data shrugs. The cost is unattributed; nobody knows what’s driving it. The conversation is “cloud is expensive” rather than “Snowflake credits on the analytics warehouse used 40% more this month than last.”
Most data teams I’ve seen in 2026 are still at this stage. The Snowflake bill, the Databricks bill, the BigQuery bill, the S3 bill, the egress bill – all visible at the top line, none broken down by team, project, or workload. The infrastructure team carries the bill and the responsibility, even though they don’t make the cost decisions.
Stage 1: visibility
The first move is attribution. Tag everything. Tag every table with its owner team. Tag every dashboard with its consumer. Tag every warehouse with its workload. Get the cost broken down by tags in the bill.
This sounds trivial. It isn’t. Most data estates have years of un-tagged resources, no governance over tagging discipline, and no enforcement at creation time. The first six months of data FinOps is mostly retroactive tagging plus policies to ensure new resources get tagged.
Once visibility exists, the conversations change. “Marketing’s pipeline is 40% of the warehouse cost” is a useful sentence in a way that “the warehouse is expensive” isn’t.
Stage 2: attribution and showback
Beyond visibility comes showback. Each team gets a regular report of what they spent. The report doesn’t need to be a chargeback (real money moving between budgets); just a clear “your dashboards cost $40K last month, here’s the breakdown.”
Showback alone changes behaviour. Engineers who don’t see the cost don’t optimise; engineers who see it usually do. The first showback report typically surfaces a few outsized line items (the dashboard that refreshes every five minutes, the ML pipeline that loads the full data daily, the orphaned warehouse nobody decommissioned). Quick wins follow.
Stage 3: budgets and accountability
Showback evolves into budgets. Each team has a quarterly allowance for warehouse compute, ML training, storage, agents. If they go over, they have a conversation with finance.
This is where data FinOps starts to bite. Budgets are real constraints. Teams have to prioritise. The cheap dashboards get built; the expensive ones require justification. Cost becomes a design input.
Most teams don’t get here. Budgeting requires organisational maturity – someone has to decide the allowance, someone has to enforce it, someone has to handle the political fallout when a team blows through it. The data team usually doesn’t have the authority to do this on its own; it needs CFO or CTO sponsorship.
Stage 4: cost as design input
The mature state. Cost is visible in the IDE. Cost is shown at design time in the BI tool. Cost shows up in PR reviews. New pipelines have a cost estimate alongside the technical design.
The teams I’ve seen at this stage have built tooling that surfaces cost where decisions are made. Their dbt projects estimate cost at compile time. Their dashboard builder shows projected monthly spend. Their agent platform shows tokens-per-question. Cost stops being a thing finance complains about and starts being a thing engineers care about, because they see it.
This stage requires investment in the FinOps tooling, not just the practice. Most off-the-shelf cloud cost tools don’t go deep enough into data-team workflows. The serious shops build their own dashboards or extend Snowflake/Databricks usage analytics.
Stage 5: continuous optimisation
The most mature data teams treat cost as something they continuously improve, the way they continuously improve performance or quality. There’s a regular cost review, a backlog of optimisation work, ownership of the bill at the engineering level.
Anomaly detection on cost, automatic right-sizing, aggressive lifecycle policies, reservation purchases informed by usage analysis – all of this is normal engineering work, applied to cost as a metric.
The cost-to-value ratio for data work, at this stage, is meaningfully better than at Stage 0. Same workloads, 40-60% less spend, no loss of capability. The savings compound over years.
Where to actually start
If you’re at Stage 0, the first three moves:
- Tag everything. Workload, owner, project. Enforce at creation time.
- Get a monthly cost-by-tag report. Distribute to teams. No drama, just visibility.
- Pick the top three line items. Optimise them. Quick wins fund the rest of the work.
From there, the path to maturity is well-trodden. It takes 12-24 months for a mid-sized data team to reach Stage 3-4. The investment pays back almost always within the first year, often within the first quarter.
The closing point
Data costs are entering the same territory as cloud costs did a decade ago. Big enough to matter, opaque enough to be hard, distributed enough that no single team owns them. The organisations that build the discipline now will have a real cost advantage in five years. The ones that don’t will keep being surprised by their bills, and the surprises will keep getting bigger.
The cost story has been the through-line of the May posts – petabyte economics, query cost as a product decision, pricing models, egress, GPUs, and now FinOps as the framework that holds them together. It’s the unglamorous half of every other topic I’ve written about over the last six months. The architecture is the work; the cost is the constraint. Both have to be taken seriously.
That’s the half-year. Onward.
