Key Insight: Many teams still manage costs on Data Cloud Platforms, like Snowflake and Databricks, at the warehouse or cluster level, which shows a component of spend but rarely explains it. Leading organizations are pushing visibility down to query level by ingesting system telemetry (query and job logs), enforcing runtime metadata (team, product, environment, purpose), and normalizing proprietary units (credits, DBUs, slots) into a consistent view aligned to FOCUS. The outcome is execution intelligence that prevents waste through engineering action, enables credible attribution in shared compute engines, and delivers data product unit economics, supporting sharper investment decisions on what to scale, tune, or retire.
Start with query and job visibility
Many organizations already use near real time monitoring, anomaly detection, and fast feedback loops for Public Cloud spend.
In Data Cloud Platforms, the visibility challenge is different. Warehouse or cluster level views can show that spend increased, and can help distribute cost, but they often aggregate many different workloads into a single consumption signal.
In shared, multi-tenant warehouses or clusters, that high-level view may not provide enough execution context to explain what drove the change or what action would improve efficiency. As a result, teams can see spend moving quickly, but may still struggle to connect it to the specific query and job behaviors that created it.
Timeliness alone does not create control. FinOps practices often benefit from execution aware visibility that links cost to what ran, why it ran, and whether it was efficient.
Teams typically need to answer questions such as:
- What ran, exactly, and what did it do?
- Who or what triggered it?
- Was it efficient, or was it wasteful behavior?
- Was the outcome worth the cost?
Tackling the query and job visibility challenge
Across mature applications of FinOps on Data Cloud Platforms, a consistent pattern is emerging within the community:
- Telemetry first: Teams are ingesting query history, job history, and system logs as a primary input for FinOps, not a nice-to-have.
- Metadata at runtime: Teams are treating query and job tagging as a control mechanism, not just an allocation technique.
- Normalization to FOCUS: Practitioners are converting proprietary units into consistent, decision-grade views, often building the transformations themselves when exports fall short.
- Execution-aware feedback loops: Programs are moving from knowing spend moved to knowing what behavior caused it, and what to do about it while it is happening.
- Decision intelligence outcomes: Query-level visibility is being used to create unit economics for data products and to support portfolio decisions, not just to report cost.
Forces driving a new visibility mandate
Virtual currencies create cost abstraction
In FinOps for Public Cloud, teams often start with dollars on an invoice and map them to resource identifiers. In Data Clouds, the “dollar” is mediated through proprietary currencies like credits (Snowflake), DBUs (Databricks Units), and slots (BigQuery). This creates an abstraction layer between technical activity and financial outcomes.
Billing artifacts may show charges, but they rarely explain the execution behaviors that created them. This becomes a friction point for organizations, because accountability depends on translating abstract tokens into a decision-grade view of cost drivers.
Example in practice: A spike in credits is visible, but the action is unclear until you can see whether it was caused by a single runaway query, an uncontrolled dashboard refresh, or an orchestration loop.
Infrastructure tags are not enough in shared compute engines
In Data Cloud Platforms, compute is frequently shared and multi-tenant. A single warehouse or cluster may serve multiple BI dashboards, run workloads for many teams, and be orchestrated through layers of tooling.
A Lead Platform Engineer at a FTSE 100 Resources Organization noted: “tagging a cluster doesn’t automatically propagate,” making it difficult to map usage per team, product, or application.
The implication is structural. Infrastructure tagging is often necessary, but insufficient. Where shared execution is the norm, visibility must follow the work.
Example in practice: A shared warehouse looks “expensive,” but you cannot separate high-value BI workloads from low-value ad-hoc experimentation without execution-level context.
Behavior, not capacity, is the dominant cost driver
In Data Clouds Platforms, cost drivers are frequently behavioral: inefficient SQL, exploding joins, unnecessary scans, orchestration patterns, and contention. Visibility that only answers “who owns the warehouse” cannot tell you whether the work performed was efficient or justified.
This is why FinOps for Data Cloud Platforms trends toward execution intelligence. The goal shifts from “who spent it” to “what did it do, and was it efficient?”
Example in practice: A cost increase is not solved by resizing alone if the real issue is a poorly filtered query scanning far more data than intended.
Runtime metadata becomes the control plane
In Public Cloud, tags often attach to infrastructure resources. In Data Cloud Platforms, attribution must attach to execution events.
The query tag becomes the practical equivalent of the resource tag because it travels with the work. FinOps practitioners and other personas are injecting metadata (team, project, environment, purpose) directly into query comments, session context, job parameters, or orchestration runtime.
A FinOps leader described Snowflake’s capability: “You can tag a query, add a comment… this is my project… it took 1 minute to run… so that minute cost you this amount.”
This is not about bureaucracy, it is about connecting execution to intent. Without intent, you can distribute the cost, but you cannot explain it. Without explanation, you cannot sustainably make informed decisions.
Turning Data Cloud Platform telemetry into decision views
FinOps practices are extending the Data Ingestion and Reporting and Analytics capabilities to handle Data Cloud Platform cost, usage, and telemetry data, not just billing exports. Instead of relying on invoices alone, they ingest platform system logs and usage tables at a practical cadence, then normalize proprietary units like credits, DBUs, and slots into consistent views that can support allocation, trend analysis, and engineering investigation.
This introduces new operating considerations. Practitioners often bridge finance reporting with engineering telemetry by mapping executions to context such as team, product, environment, and workload purpose. The work commonly includes:
- Ingest execution telemetry on a tiered operational cadence, such as intraday for control loops, daily for allocation, weekly for optimization, and monthly for governance.
- Transform credits, DBUs, and slots into consistent cost and usage fields
- Map execution events to owners and purposes using runtime metadata
- Provide both allocation views and engineering diagnostic views
- Feed results back into engineering workflows, not just dashboards, such as tickets, continuous integration pipeline (CI) gates, runbooks, routing
Corey Syvenky, Cloud and Data Architect at Teck Resources, described the transformation work required: “Nearly 200 lines of SQL [it’s] necessary to conform Databricks billing data with FOCUS.”
This is the operationalization threshold. When teams can repeatedly turn telemetry into a finance, comparable model like FOCUS, they move from cost reporting to cost control at the execution layer.
Databricks now provides data in FOCUS format (private preview) and Snowflake is planning to provide this in 2026. This is a definitive signal that proprietary billing formats and coarse-grained exports were becoming blockers to providing actionable-data and execution-level intelligence.
Moving from warehouse showback to query-level attribution
Ownership is a starting point in any consumption model, but in Data Cloud Platforms it is not enough. Shared warehouse spend only becomes actionable when you attribute it to the queries and jobs that actually ran, so you can name an accountable owner and assess whether that execution was efficient and valuable versus the cost to run it.
A FinOps Lead from a Global Shipping and Logistics organization highlighted that meaningful savings came from deep execution-level analysis: “[The team] just dug into their biggest spend… diving into what jobs they’ve run and what queries they’ve run.”
Query and job visibility enable:
- Identifying the highest-cost executions and their causes
- Detecting wasteful patterns that cannot be seen at warehouse level
- Connecting spend to the actual consumers of work in shared environments
- Moving from showback to true consumption attribution
When organizations can see “what ran” and “why it cost that much” they stop treating the Data Cloud Platform bill as a black box, and start treating it as an engineering system that can be tuned.
Shift left: Execution-aware anti-pattern detection
Visibility alone is not enough if it arrives too late, or if it cannot drive action. The next evolution is to shift from retrospective reporting to execution-aware feedback that helps engineers prevent waste while work is being performed.
The key distinction is not “month-end vs real-time.” Many cloud programs already operate in near real time. The distinction is “billing-derived signals vs execution-aware signals.” Billing signals can tell you spend moved. Execution signals can tell you what behavior caused it, and what to do about it at the time of action.
This changes the role of FinOps for Data Cloud Platforms. It evolves from reporting cost to tuning query performance and enforcing efficiency standards as part of the platform operating model.
From execution intelligence to data product decisions
Query-level visibility is not an end in itself. It becomes strategically important when it enables business value decisions that were previously made on assumptions.
Once execution telemetry is mapped to metadata (product, team, environment, purpose), organizations can build decision insights such as:
- Data product unit economics: cost per dashboard, per pipeline, per model run, per customer segment insight
- Trade-offs with intent: freshness vs cost, latency vs cost, accuracy vs cost, compliance vs cost
- Portfolio prioritization: which data products to scale, re-architect, throttle, or retire
- Investment governance: when commitments and capacity strategies are justified by workload behavior, not by coarse warehouse averages
When visibility reaches query and job level, FinOps practices deliver additional efficiency. When that efficiency is tied to data product intent and outcomes, FinOps data enables leaders on decisions to invest, prioritize, and govern technology value with more confidence.
Further learning
- FinOps for Data Cloud Platforms
- Context for Building a FinOps Scope for Data Clouds
- August 2025 Summit: FinOps for Data Clouds
- Transforming Databricks Cost Management into the FOCUS format: A Practical Guide
- Snowflake Optimization and the Future of Cloud Efficiency
Topics
-
FinOps Foundation Perspectives
