Organisations are being charged by modern data platforms based on how their systems execute tasks, rather than the capacity of their infrastructure. This means that the design of queries, how often they are run, and the logic used to transform data all contribute to the overall cost. Traditional financial operations (FinOps) frameworks, which provide a high-level view of costs and budget allocation across different cloud environments, are not effective in controlling these costs. They fail to identify the specific software pipelines or machine learning models that are causing cost spikes. To effectively manage costs, organisations need to extend their financial management down to the level of individual system executions and up to the design of their architecture.
Understanding the costs of modern data platforms
The expenses associated with modern data platforms are driven by the execution of queries, the dependencies between different pipelines, and the consumption of tokens, rather than the uptime of static infrastructure. On platforms like Snowflake, Google BigQuery, and Databricks, costs are incurred every time code is executed against raw or transformed data. To understand these costs, it is necessary to evaluate the factors that drive them, including the virtual billing units and shared compute environments.
The bills for these platforms reflect how efficiently the system is executing tasks, rather than the amount of hardware that has been provisioned over time. Organisations often work with specialists like Future Processing to identify the structural limitations that are driving up costs without a clear operational cause. Inefficient queries, exploding joins, unnecessary full table scans, and high-frequency dashboard refresh loops can all consume significant resources.
Data engineers write transformations that run against live datasets that are constantly growing. A pipeline or dbt model that runs safely in development can experience exponential cost growth when it is deployed to production and the volume of data increases, even if the underlying query code remains the same. The use of virtual currencies can obscure the relationship between technical execution and financial output.
A sudden increase in credit or unit consumption can alert finance teams to the fact that spending has increased, but raw billing metrics do not provide enough information to determine whether an unoptimised join, a runaway orchestration loop, or a multi-tenant dashboard query is the cause of the spike. The shared nature of these environments makes it difficult to attribute costs to specific individuals or teams.
Data cloud compute resources are often shared among multiple business units, analytical tools, and pipeline orchestration layers. A single data warehouse may run transformation jobs, executive BI dashboards, and ad-hoc data science queries simultaneously. While resource-level cloud tags can identify the container, they do not travel with individual execution tasks inside the warehouse. When multiple departments query shared datasets, attributing costs to specific teams can lead to internal disputes rather than clear operational ownership. This means that even if the finance team knows which department is spending the most, they cannot easily determine whether the department is using its budget effectively or efficiently.
The limitations of traditional FinOps
Traditional FinOps practices are not effective in controlling the costs of modern data platforms because they are designed for static infrastructure, rather than dynamic, query-driven execution. Standard frameworks optimise compute uptime, memory, and network storage, but modern consumption-based data engines generate costs through query logic, transformation routines, and pipeline dependencies. Organisations that try to constrain data platform expenses using traditional infrastructure telemetry face several structural limitations.
The reporting trap and the tagging illusion can further complicate the issue. Resource tagging can identify the owner of a particular cost, but it does not optimise unperformant code. Traditional FinOps generates monthly spend reports categorised by cloud account, business unit, and environment, but these reports do not provide enough detail to understand the architectural choices that are driving costs.
While engineers frequently see alerts about rising database expenses, they lack the detailed technical insights needed to pinpoint inefficient queries causing the spikes. Assigning responsibility for costs to a database cluster helps identify the responsible team, but it doesn’t provide enough granularity to motivate developers to fix poorly indexed joins or inefficient full-table scans. Most cost increases in modern data platforms stem from flawed design choices rather than inefficient resource use. Issues like broken data tracking, redundant pipelines, uncontrolled table expansion, and uncoordinated data transformations can operate continuously without setting off standard cloud spending alerts. Traditional FinOps tools track capacity usage and idle resources but miss unnecessary orchestration tasks, abandoned datasets, or inefficient dbt scripts repeatedly processing massive historical datasets.
Capacity reservations and savings plans
While capacity reservations and savings plans can cut costs temporarily, they don’t address the deeper engineering habits driving expenses. Without changing how teams design and deploy workloads, spending will continue climbing. True cost efficiency demands restructuring how data engineering teams approach development, testing, and deployment. Leadership should connect financial data directly to daily engineering decisions, pairing execution metrics with design safeguards to create lasting cost management frameworks.
Extending FinOps into FinDataOps
Managing expenses in modern data platforms requires expanding FinOps into a full FinDataOps framework that integrates financial oversight with DataOps and MLOps workflows. This approach moves beyond monthly financial summaries to provide real-time operational insights, early-stage governance, and precise cost tracking for data products. FinDataOps uses runtime data to link query logs, job histories, and system events to specific cost centers. Engineers embed structured metadata—such as team identifiers, environment details, project codes, and business purposes—directly into query annotations and session parameters. These tags follow execution tasks across shared data warehouses, allowing costs to be accurately assigned to individual pipelines, data products, and business units when normalized to standards like the FinOps Open Cost and Usage Specification (FOCUS).
