Today we are publishing FinOps for Data, a Fortified research paper on one of the largest blind spots in FinOps practice: the cost of data and database technology. DBMS spending is growing faster than IT spending overall, yet most organizations still cannot connect that spend to the workloads driving it.
Get the paper:
https://fortified.com/finops-for-data-whitepaper
Why this paper, and why now
In February 2026, the FinOps Foundation’s governing board changed its mission statement by exactly one word: “advancing the people who manage the value of cloud” became “the value of technology.” Explaining the change in a Foundation article, board member J.R. Storment wrote, “This is not a cloud cost discipline anymore.” The framework revisions that followed in March formally brought licensing, private cloud, and the data center inside the discipline’s scope.
That expansion points straight at the data estate, and the data estate is where the discipline’s standard toolkit stops working. Gartner forecasts DBMS market growth of 18.4 percent in 2026, compared with 14.2 percent for IT spending overall. Flexera’s 2026 State of the Cloud reports wasted cloud spend rising to 29 percent, the first increase in five years, driven by AI workloads that are, underneath, data workloads. The money is large, it is growing, and almost nobody can say what any given unit of database work actually costs.
The argument
The paper’s thesis fits in one sentence: the unit the bill reports is never the unit of decision. The bill tells you what you spent. The query tells you why.
A real data estate runs four cost models at once:
- Consumption-metered (Snowflake, BigQuery, Databricks): the meter sits near the work, and this is the only model standard FinOps practice fully fits.
- Provisioned managed (Azure SQL, RDS, Aurora): the meter measures the box, not the workloads sharing it.
- Licensed self-hosted (SQL Server, Oracle, Db2): the discipline does not get harder here. It breaks. There is no bill at all – capacity was bought years ago under entitlement rules, so a discipline whose data layer ingests billing datasets has no input.
- Open-source self-hosted (PostgreSQL, MySQL): the license line is zero, which is exactly what makes it deceptive. The real costs, infrastructure and engineering time, appear on no meter anywhere.
Cloud cost platforms ingest bills, so their granularity ends where the bill’s does: at the resource. Database monitoring tools see workloads in CPU, reads, waits, and executions, but not in dollars. Both toolchains stop one layer short of workload-level cost attribution. Across all four cost models, the workload is the shared unit of attribution; a query, statement, stored procedure, job, or batch is the operational grain.
We reviewed the published capabilities of major cloud cost platforms and six database tools in July, then repeated the review in September. The landscape moved, but one finding did not: among the products reviewed, none attributed SQL Server cost in dollars at query grain. Tooling follows the meter. Where the meter stops, the tooling generally stops with it.
What a practitioner can do about it
The second half of the paper is practice, not diagnosis, and none of it requires buying anything:
- A five-level maturity model for database estates – Unmeasured, Bill-visible, Workload-visible, Dollar-attributed, Value-governed – mapped onto the FinOps Foundation’s own Crawl/Walk/Run spine so it locates inside an existing practice rather than beside it.
- An ownership arrangement pairing database expertise with FinOps expertise, because the handoff between those two roles is where cost accountability most often fails.
- An operating loop we call find, fix, prove: surface the expensive workloads, fix them in the code, and prove the savings in dollars – a dollar value Finance can use, not another page of operational metrics.
- A 90-day instrumentation sequence built on native platform telemetry. SQL Server’s management views have shipped per-query CPU, reads, and execution counts for two decades. The missing capability is conversion, not measurement: multiply the telemetry by a rate and hand Finance a number.
Test it against your own estate
The paper distinguishes clearly between what the sources establish and what we have observed in practice. It is written so readers can test those observations against their own estates: assess current maturity, identify the workloads driving cost, run find-fix-prove, and use the 90-day sequence to build repeatable attribution with native telemetry.
Get FinOps for Data: Get the paper:
https://fortified.com/finops-for-data-whitepaper
FinOps for Data was written by lead author Douglas McDowell, Fortified’s COO, a FinOps Certified Professional and former general manager of SolarWinds’ database monitoring business, with contributing author Ben DeBow, CEO of Fortified and author of End of Abundance in Tech (Forbes Books, 2023). Every external claim in the paper carries its source and its access date.