Blog

Databricks FinOps: Practical Optimization Strategies and Real-World Examples

Kacper Glugla

September 25, 2026
10 minutes
‌

In the world of modern data platforms, the promise of the cloud is all about boundless scalability and innovation. Cloud platforms make it easy to scale data and AI workloads; yet this is a double-edged sword. While the freedom to scale is powerful, without proper control it easily leads to underutilized compute, inefficient workloads, increased storage costs, limited cost attribution across teams, and ultimately excessive spend and losses for the organization. Xebia's recent webinar "FinOps for Databricks Platform: Operational Efficiency in the Lakehouse Era" has delved into this very challenge.

This article explores practical FinOps strategies for Databricks based on insights and key themes from that session. Find out how to improve cost visibility using Databricks System Tables, implement proactive monitoring, optimize compute and storage resources, and identify opportunities to reduce unnecessary cloud spending. We will also look at real optimization examples, such as how to reach 75% compute optimization for streaming workflow and more than $30,000 in monthly savings through proper SQL Warehouse settings.

From CapEx to OpEx: Why Cloud Cost Management Approach Matters

To understand why cost management is so critical, let's look at what happened when the cloud was introduced. Before, costs were primarily Capital Expenditures (CapEx): buying servers, storage, and racks, thus investing heavily upfront. With CapEx, costs could be predicted with high accuracy, but when moving to the cloud, that heavy lifting is handed off to the cloud vendors. The cost model transforms into Operational Expenditures (OpEx), meaning you pay for what you use, whether it's storage, CPU time, or network resources.

This shift changes everything because it allows for flexibility and experimentation. However, it introduces a new challenge, that without the physical constraints to physical hardware, it's very easy to spin up virtual resources and lose track of spending, same as you easily lose track of spending money using credit cards compared to cash. Unlike CapEx, OpEx can at best be estimated; and even those estimates remain uncertain, because every new process or workload has the potential to generate significant additional costs, making reliable budget planning far more difficult.

Understanding Databricks Cost Model 

The webinar highlighted how the evolution of data architecture plays a role in both the power and the complexity of cost management. The journey has moved from the rigid, expensive, and locked-in data warehouses to the more flexible Data Lakehouse architecture.

The Data Lakehouse architecture is about the separation of storage and compute resources. In a traditional data warehouse, these components remain tightly coupled, resulting in continuous utilization of compute resources, even during periods of inactivity like nighttime or weekend. By contrast, a Data Lakehouse permits the provisioning of compute resources solely for data processing, followed by their subsequent termination upon completion of the workload, ensuring that you pay only for the required time of compute resource.

This is where technologies such as Apache Spark demonstrate their value. Spark uses a driver node that partitions a large dataset into small tasks and distributes them among worker nodes for parallel processing. This architecture enables the handling of extensive datasets with exceptional efficiency. Therefore, it presents a significant challenge: ensuring that compute resources are not over-provisioned for workloads that do not require such capacity. This is where the right compute adjustment is crucial.

Within this ecosystem, the Delta Lake table format introduces an additional layer of management responsibility. Every insert, update, or delete operation generates a new file. In the absence of regular execution of the OPTIMIZE and VACUUM commands to compact small files and remove obsolete data, the result is frequently a severe degradation in performance accompanied by elevated storage costs.

Although Databricks has automated these maintenance operations through Predictive Optimization for Unity Catalog managed tables (available from Databricks Runtime 12.2), a substantial number of tables continue to have a suboptimal file count on the storage. This condition translates directly into slower query execution, longer data processing, and increased platform costs.

The Supermarket Analogy: Why Databricks Costs Get So Hard to Track 

To really understand how complex cost management gets on Databricks, let's picture a supermarket.

Level 1: You do the shopping yourself and get a receipt right after each trip, showing exactly what every item cost. Easy to track.

Level 2: You still shop alone, but now you only get one monthly bill that lists every item, and your account is charged automatically. Still manageable, just a bit more work to check.

Level 3: You and the rest of the household shop separately. Everything ends up on a single monthly bill that still shows individual items, and the account is charged automatically. This is where things start getting messy.

Level 4: Same household, same separate shopping, but the monthly bill now groups everything into categories (bakery, vegetables, drinks…). You can no longer see exactly which items were bought, nor who bought them.

Level 5: Now the whole extended family (aunts, uncles, cousins, grandparents) shop independently. You still get one monthly bill, costs only shown by category. Spotting who bought what becomes impossible.

Level 6: And at the highest level… there's one family member who spends the most money in a completely thoughtless and reckless way (grabbing everything without a second thought) and ends up generating the majority of the costs and you don't know who it is.

This is exactly why a FinOps strategy matters, because it's both a cultural shift and a practical framework for keeping cloud spending under control.

FinOps for Databricks: A Practical Strategies

A FinOps tool alone might be efficient, but without an experienced Data Engineer behind it, it can also fall behind. Coupling an experienced Data Engineer with the right tool can benefit your company by optimizing Spark workloads, solving bottlenecks, and helping you to apply the right tool for the specific task that you require.

In the webinar, we explored also a practical solution to move from chaos to control, focusing on several key areas.

Visibility Before Optimization 

Before diving into specific optimization tactics, it's crucial to understand a fundamental principle of FinOps: you cannot optimize what you cannot see.

Without clear visibility, any optimization effort is essentially guesswork. You might stumble upon a few obvious fixes, but you'll never have a comprehensive understanding of your cost drivers. The Pareto principle applies here: in many organizations, the webinar noted that roughly 20% of processes are responsible for 80% of wasted resources. But without the data it is impossible to identify and optimize them.

Operational insights, the ability to see exactly what's running, who's running it, and how much it costs, form the bedrock of any successful FinOps strategy. These insights empower you to attribute costs accurately to specific teams or projects and identify anomalies before they become too big.

Only when you have this visibility can you move from trying to put out fires to proactive cost management. With that foundation in place, let's explore which specific steps you can take to gain control.

Step 1: Cost Attribution and Visibility 

The first and most crucial step to controlling costs is knowing where the money is going. This starts with tagging all compute resources (clusters, jobs, warehouses). By enforcing a policy of tagging resources with identifiers like "Department", "Project", or "Environment" (e.g., dev, prod), it is possible to start slicing and dicing your costs. The Databricks platform captures this information in its system tables, providing a rich source of operational metadata.

But system tables alone aren't enough. The webinar highlighted that you also need to gather data not readily available in system tables, such as:

  • Delta Table metadata (size, number of files, last query time).
  • Storage metadata (size of each folder).
  • A mapping of workspace and service principal IDs to meaningful names.
  • Cloud infrastructure costs for classic compute (VMs).

Step 2: Proactive Monitoring and Alerts 

You shouldn't wait for the end-of-month bill to find out there's already a hidden problem. The FinOps approach includes setting up alerts for cost anomalies and budgets for different departments or projects. This lets you stay active rather than reactive.

Thanks to the monitoring module, you can catch a cost spike early, before it has time to grow and accumulate into a much larger problem by the end of the month. If a spike starts on Tuesday, the alert can notify you as early as Wednesday, giving you time to investigate and stop the waste early.

Step 3: Optimization (The Real-World Examples)

The webinar was rich with real-world examples of how these strategies lead to dramatic savings.

  • The idle 24/7 warehouse: A customer had a SQL warehouse that was left running 24/7 just to refresh a report every hour. The FinOps tool detected this, and by simply switching the configuration to serverless and adjusting the auto-termination time, the monthly cost dropped from a whopping $30,000 to just $3,000.
  • Over-provisioned compute: In another case, a massive cluster with a minimum of 18 workers and a maximum of 24 (each with 32 cores and 128GB of memory) was running 24/7. An analysis showed that the CPU utilization for them was almost zero. By right-sizing the cluster, the customer saved 75% on that single workload, reducing the cost from $200/hour to $50/hour.
  • The 140 terabyte table: A single table was taking up 140 terabytes of expensive storage because it had never been vacuumed. This represented an annual cost of $21,000 for just one single table, a problem that is far more common than many realize in large organizations.
  • The duplicate streaming job: Two different departments had created nearly identical streaming jobs to pull the same data from Kafka, doubling the cost unnecessarily. The visibility provided by the FinOps tool identified this duplication, allowing one job to be shut down.

But again, the FinOps tool alone might not be enough. The greatest value comes from combining the right platform, operational data (such as Databricks System Tables) and engineering expertise.

Key Takeaways: Gaining Control 

The ultimate message of the webinar is that you will always have some waste on the cloud. It's in the nature of the model. However, by implementing a structured FinOps approach, that waste is constantly under your direct control. You can stop overpaying for storage and compute, make your processes run faster by properly maintaining tables and right-sizing resources, and keep a clear, actionable view of your cloud expenditure.

For organizations using Databricks, the path forward involves:

  1. Implementing a robust tagging strategy to attribute costs correctly.
  2. Building dashboards and alerts to monitor usage and identify anomalies as quickly as possible.
  3. Enforcing policies on compute resources to prevent over-provisioning and idle waste.
  4. Regularly reviewing data tables for optimization opportunities and unused storage.

Having a FinOps tool is powerful, but combining it with the expertise of an experienced data engineer who can understand and optimize Spark workloads is where you unlock the true potential of your data platform. The journey from chaos to control is achievable, and the benefits to both your budget and your platform's performance are increasingly hard to deny.

Start your journey with Xebia today by finding out more about Lake Warden.

Want to keep exploring what's possible on Databricks?

Cost efficiency is only one part of running a mature Databricks environment. Governance and accessibility matter just as much. Join our Talk To Your Data webinar series, based on real project cases:

Talk To Your Data: GDPR-Ready on Databricks
Build a governed, GDPR-compliant data foundation with Unity Catalog.
October 8, 114:00 CET | 08:00 EDT | 07:00 CDT | 17:30 IST | Register here

Talk To Your Data: Conversational Analytics for Business Teams
See how business teams can ask data questions in natural language with Genie Agents, no SQL required.
October 22, 14:00 CET | 08:00 EDT | 07:00 CDT | 17:30 IST | Register here

Frequently Asked Questions About FinOps for Databricks

Written by

Kacper Glugla

Contact

Let’s discuss how we can support your journey.

‌
‌
‌
‌
‌
‌
‌
‌
‌