Databricks Cost Optimization: How to Cut DBU and Compute Spend in 2026

If you're running Databricks at scale, you've probably noticed something troubling: the bill keeps climbing even when your workload volume stays relatively flat. Practitioners report monthly Databricks costs in the tens of thousands—sometimes with no clear line of sight to where the spend is actually going.

The problem isn't Databricks itself. It's that most teams optimize only one layer of a two-layer cost model, leaving significant waste in the blind spot. Databricks bills have two distinct components: the Databricks Units (DBUs) you pay Databricks for compute time, and the cloud infrastructure underneath—EC2 instances on AWS, virtual machines on Azure, or Compute Engine instances on GCP—that you pay your cloud provider for directly.

This guide walks through both layers: how Databricks pricing actually works, where spend leaks in real production environments, and how to optimize compute at the DBU level and infrastructure at the cloud provider level.

How Databricks Pricing Actually Works

We’ll start by breaking down the two-layer cost model and the primary factors driving spend, with best practices and Databricks cost optimization examples.

Layer 1: DBUs (what you pay Databricks)

A Databricks Unit (DBU) is Databricks' pricing unit for compute time. One DBU represents a normalized measure of processing capacity per hour. The DBU rate you pay depends on three variables: your pricing tier (Standard vs Premium vs Enterprise), the workload type (job compute, all-purpose compute, SQL warehouses, serverless), and whether specific features like Photon are enabled.

For example, on AWS Premium tier, all-purpose compute costs $0.55 per DBU, while job compute costs $0.15 per DBU—a 3.7x difference for the same underlying instance. On Azure, the Standard tier (which retires on October 1, 2026) carries lower DBU rates, but organizations are being forced to migrate to Premium, which effectively increases the DBU cost per workload. Organizations on Standard tier on Azure will be automatically migrated to Premium, which carries higher DBU rates.

The DBU layer scales with cluster size and runtime. A 10-node cluster running for 2 hours at 1 DBU per node-hour generates 20 total DBUs billed. Photon adds a premium (a 2.9x DBU emission rate vs. non-Photon for Lakeflow Jobs Classic) but can reduce query runtime by 50% or more, making it cost-neutral or cost-positive for the right workloads.

Layer 2: the cloud VMs underneath (what you pay AWS/Azure/GCP)

Databricks classic compute clusters—the most common deployment model—run on virtual machines in your own cloud account. Every node in a Databricks cluster is backed by an EC2 instance (AWS), an Azure VM, or a GCE instance (GCP) that you pay for separately, in addition to the DBU charges.

These VMs appear as standard compute line items on your AWS, Azure, or GCP bill. A 10-node cluster running on AWS r6i.2xlarge instances for 2 hours generates both the Databricks DBU charge and 20 hours of EC2 instance usage at the on-demand or Spot rate for that instance family.

The cloud infrastructure bill is often larger than the DBU bill, especially for memory-optimized or GPU-accelerated workloads.  

Storage, data transfer, and egress costs add a third layer. Databricks workloads pull data from S3, ADLS, or GCS, and that I/O generates storage API request charges and egress fees when data crosses regions or other chargeable network boundaries. For large-scale ETL pipelines processing terabytes daily, egress can represent 5-15% of total monthly Databricks-related spend.

Why most teams only optimize one layer

FinOps teams focused on cloud spend see the VM line items and apply standard EC2 optimization—Reserved Instances, Savings Plans, rightsizing recommendations. But those tools don't understand Databricks cluster policies, auto-termination logic, or the distinction between job compute and all-purpose compute, so they miss opportunities to shift workloads to cheaper DBU rates or enforce idle cluster shutdowns.

Data engineering teams, meanwhile, focus on the Databricks console: cluster configurations, autoscaling settings, Photon enablement. But they rarely have visibility into whether the underlying VMs are using Spot instances, whether Reserved Instances are covering the compute, or whether storage tiering is configured correctly.

The result: partial optimization. You might cut DBU waste by 20% with better cluster policies, but the VMs underneath still run on-demand at full price. Or you might lock in a 1-year Reserved Instance commitment for your cluster fleet, but idle all-purpose clusters burn through that commitment even when no jobs are running.

Where Databricks Spend Leaks

Before optimizing, it's helpful to understand where waste accumulates in real production Databricks environments. The most expensive mistakes fall into five categories.

Idle all-purpose clusters

All-purpose clusters are designed for interactive notebook work. They stay warm between queries so data scientists and analysts can iterate quickly. The problem: all-purpose compute costs 2-4x more per DBU than job compute, and these clusters frequently sit idle for hours—or days—between active sessions.

Organizations often provision all-purpose clusters for exploratory work and forget to terminate them. A single m5.4xlarge all-purpose cluster running 24/7 on AWS Premium can cost $600-800/month in DBUs alone, before counting the EC2 instance cost underneath. Multiply that across a team of 20 data scientists, and idle all-purpose clusters become the single largest controllable expense.

Auto-termination mitigates this, but if it isn't configured, an all-purpose cluster won't terminate automatically. Tightening auto-termination to 15-30 minutes for interactive clusters cuts idle burn without degrading the developer experience.

Oversized drivers and workers

Databricks clusters consist of one driver node and N worker nodes. The driver orchestrates tasks and collects results; workers execute the actual Spark transformations. Many teams provision the driver and workers symmetrically—10 r6i.4xlarge nodes across the board—because it's simple. But most workloads don't need a driver with 128 GB of memory and 16 vCPUs.

Oversizing the driver wastes both DBU hours and VM costs. A right-sized driver for a typical ETL job might be a r6i.xlarge (4 vCPUs, 32 GB), saving 75% of the driver's compute cost compared to a r6i.4xlarge, with no performance impact. Worker sizing matters more—underpowered workers create bottlenecks—but driver sizing is pure overhead.

Long-running interactive notebooks

Interactive notebooks are a productivity tool, not a production runtime. Yet many organizations run scheduled jobs from notebooks pinned to all-purpose clusters because it's the path of least resistance during prototyping. These jobs inherit the all-purpose DBU price ($0.55/DBU on AWS Premium) instead of the job compute price ($0.15/DBU), a 3.7x markup for identical work.

Migrating scheduled workloads from notebooks + all-purpose clusters to Databricks Jobs + job compute clusters is one of the highest-ROI optimization moves available. A nightly ETL pipeline running 2 hours/day on a 10-node all-purpose cluster that consumes 40 DBUs/day costs $22/day at $0.55/DBU. Refactoring it to job compute at $0.15/DBU cuts the Databricks charge to $6/day—a $16/day savings, or ~$480/month in DBU costs alone for that single pipeline.

Inefficient Delta tables and small-file problems

Databricks is built on Delta Lake, and current Databricks autotuning targets file sizes from 256 MB up to 1 GB. Streaming ingestion, frequent small writes, and poorly tuned MERGE operations can fragment tables into thousands of tiny files. Small-file problems increase query planning overhead, slow down reads, and force more parallelism than necessary—all of which translate to longer cluster runtimes and higher DBU consumption.

OPTIMIZE and VACUUM are the complementary maintenance tools. OPTIMIZE coalesces small files into right-sized files; VACUUM removes old file versions that accumulate after updates and deletes. Running OPTIMIZE weekly on high-churn tables can reduce query runtimes by 30-50%, directly cutting DBU spend and improving end-user latency.

Serverless convenience premiums

Databricks Serverless compute abstracts away cluster management entirely. You write SQL, submit it, and Databricks provisions the compute on-demand. No cluster configuration, no auto-termination settings, no manual scaling. For teams without deep Spark expertise, serverless is a game-changer.

The trade-off: serverless bundles infrastructure costs into the DBU pricing, so the DBU rate is higher than classic compute. For workloads that run frequently and benefit from cluster reuse, classic compute on job clusters is more cost-efficient. For ad-hoc queries and dashboards with unpredictable access patterns, serverless makes sense. The mistake is defaulting to serverless for all workloads without evaluating the cost-performance trade-off per use case.

Compute-Layer Optimization (the DBU side)

The DBU layer is where Databricks-native levers live: workload type selection, runtime configuration, and cluster lifecycle policies. Optimizing DBUs requires understanding how Databricks prices different compute modalities and enforcing discipline across teams.

Job compute vs all-purpose compute vs SQL warehouses

Databricks offers three compute categories, each with a different DBU rate and use case:

• Job compute: Designed for automated, production workloads. Clusters start on-demand, run the job, then terminate. DBU rate: $0.15 / DBU (AWS Premium). Use for: scheduled ETL pipelines, batch transformations, nightly aggregations.
• All-purpose compute: Designed for interactive development. Clusters persist between queries to minimize startup latency. DBU rate: $0.55 / DBU (AWS Premium). Use for: notebook experimentation, exploratory data analysis, prototyping.
• SQL warehouses: Optimized for BI queries and dashboards. Photon-enabled by default. DBU rate: $0.22 / DBU for Classic SQL warehouses (AWS Premium), higher for Serverless SQL. Use for: Power BI / Tableau integration, analyst self-service queries, real-time dashboards.

The fastest way to cut DBU costs is to audit workload placement. Any scheduled job running on an all-purpose cluster should migrate to a job cluster. Any dashboard query running on an all-purpose cluster should migrate to a SQL warehouse. A 10-team data platform with 50 pipelines running on all-purpose clusters can save $15,000-30,000/month in DBU costs by refactoring to job compute.

Auto-termination and auto-scaling settings

Auto-termination controls how long a cluster stays warm after the last active query. If auto-termination isn't set for an all-purpose cluster, the cluster won't terminate automatically; job clusters terminate automatically after job completion. Tightening auto-termination to 15-30 minutes for all-purpose clusters eliminates idle burn without meaningfully impacting the user experience. Most data scientists tolerate a 2-3 minute cluster startup delay if it means they don't need to manually shut down clusters.

Auto-scaling adjusts the number of worker nodes dynamically based on workload. Databricks evaluates pending tasks and scales up when parallelism is constrained, then scales down when tasks complete. Enabling auto-scaling on job clusters prevents over-provisioning: instead of allocating a fixed 20-node cluster for a job that only needs 20 nodes for the first 10 minutes and 5 nodes for the next 50 minutes, auto-scaling allocates 20 nodes at peak and scales down to 5 afterward. This cuts DBU consumption and VM costs proportionally.

The catch: auto-scaling introduces a small performance overhead during scale-down events (Spark needs to rebalance tasks) and doesn't help if your jobs are consistently bottlenecked on a single slow stage. Right-sizing the min/max node range requires profiling actual job execution patterns. Start with min=2, max=10 for exploratory pipelines, then tune based on observed utilization.

Choosing the right Databricks Runtime version

Starting with Databricks Runtime 19, each DBR version has an approximately six-month GA feature-development phase. Each new runtime includes Spark version updates, performance patches, and incremental improvements to Photon. Organizations often pin clusters to older runtime versions for stability, but older runtimes miss cumulative performance gains that translate directly to lower DBU consumption.

DBR 13.x introduced vectorized Delta readers, which reduced read-heavy query times by 15-25% compared to DBR 12.x. DBR 14.x extended Photon coverage to more SQL functions, cutting DBU usage for complex aggregations. Upgrading from DBR 11.x to DBR 14.x can reduce pipeline runtimes by 30-40% for the same workload, purely through runtime optimizations.

The trade-off is that new runtimes occasionally introduce regressions or breaking changes. The safe cadence is to upgrade to the latest LTS (Long-Term Support) runtime once per quarter, validate performance on dev/staging clusters, then roll it out to production job clusters. LTS runtimes receive 3 years of bug fixes and security patches, providing a stable upgrade path.

Photon: when the DBU premium pays for itself

Photon is Databricks' native vectorized query engine, written in C++ to replace parts of Spark's JVM-based execution. Photon accelerates SQL queries, Delta reads, aggregations, joins, and window functions by 2-5x compared to standard Spark execution. The cost: on AWS Lakeflow Jobs Classic, Photon has the same $0.15/DBU price as non-Photon compute but a 2.9x higher DBU emission rate.

Photon can pay for itself when queries run ≥2x faster, because halving runtime also halves the underlying VM runtime, which can offset the higher Photon DBU consumption. For workloads that accelerate 3-5x with Photon—common for scan-heavy queries on wide Delta tables—Photon reduces both DBU cost and overall runtime.

Where Photon doesn't help: Python UDFs, RDD operations, and custom Spark code outside the SQL/DataFrame API. Photon accelerates SQL and DataFrame transformations, not arbitrary Python execution. Enabling Photon on clusters that run primarily PySpark UDFs incurs the 2.9x higher DBU emission rate with minimal performance improvement.

The evaluation process: enable Photon on a clone of your production job cluster, run the same workload, compare runtime and DBU consumption. If runtime drops ≥50%, enable Photon in production. If runtime drops 20-40%, evaluate whether the latency improvement justifies the higher DBU cost. If runtime drops <20%, disable Photon.

Cluster policies to enforce guardrails at scale

Cluster policies are JSON-based templates that define allowed cluster configurations: instance types, DBR versions, auto-termination windows, Photon enablement, and autoscaling ranges. Policies enforce organizational standards and prevent users from provisioning expensive or misconfigured clusters.  

A common policy structure:

• Interactive-dev policy: Restricts all-purpose clusters to m5.xlarge to m5.2xlarge instance types, enforces 15-minute auto-termination, limits max nodes to 5, requires latest LTS runtime
• Production-job policy: Allows job clusters on r6i.large to r6i.4xlarge instances, enables autoscaling (min 2, max 20), enforces Photon for SQL-heavy workloads, requires DBR 18 LTS
• Analytics-SQL policy: Forces SQL warehouses to Classic tier (not Serverless), restricts to T-shirt sizes S/M, enforces 10-minute auto-stop

Cluster policies act as cost guardrails. Without policies, a single data scientist can accidentally provision a 50-node all-purpose cluster on r6i.8xlarge instances and leave it running over the weekend, generating $5,000+ in unintended costs. With policies, the cluster creation fails at submission.

Infrastructure-Layer Optimization (the cloud side)

The cloud infrastructure underneath Databricks clusters—EC2 instances, Azure VMs, Compute Engine instances—represents 50-70% of total Databricks-related spend for most organizations. Databricks cost optimization best practices require applying cloud-native cost strategies (Spot instances, Reserved Instances, Savings Plans, rightsizing) in a way that respects Databricks cluster lifecycle and fault tolerance requirements.

Spot/Fleet instances for workers, on-demand for drivers

Spot instances (AWS), Spot VMs (Azure), and Preemptible VMs (GCP) offer 60-90% discounts compared to on-demand pricing, with the caveat that the cloud provider can reclaim them with 30-120 seconds' notice when capacity is needed elsewhere. Databricks job clusters tolerate Spot interruptions gracefully: when a worker node is reclaimed, Spark reschedules the tasks to remaining workers or newly provisioned replacement nodes. Drivers, however, are single points of failure—losing the driver node kills the entire job.

The safe Spot configuration:

• Workers: 100% Spot instances (or 80% Spot + 20% on-demand for workloads that require strict SLA compliance)
• Driver: 100% on-demand

This configuration captures 60-80% of the infrastructure cost savings from Spot pricing while maintaining job reliability. For a 20-node job cluster (1 driver + 19 workers), 95% of the VM cost comes from workers, so applying Spot to workers alone delivers near-maximum savings with minimal risk.

Databricks supports Spot natively through cluster configuration. On AWS, enable "Use Spot instances" in the cluster UI and set the "Max Spot price" to on-demand pricing (so Databricks bids up to on-demand, but only pays the current Spot market rate). On Azure, configure "Azure Spot VMs" for worker nodes. On GCP, select "Preemptible VMs" for workers.

The exception: streaming workloads with strict latency SLAs (e.g., real-time fraud detection, live dashboards) should run on on-demand workers to avoid Spot interruption delays. For batch ETL and nightly aggregations, Spot is the default choice.

Instance family selection (memory vs compute optimized)

Databricks workloads fall into two categories: compute-bound (CPU-intensive transformations, complex aggregations) and memory-bound (large joins, wide DataFrames, caching). Matching the instance family to the workload type cuts costs by 20-40% compared to using general-purpose instances everywhere.

• Compute-optimized (c5, c6i on AWS; F-series on Azure): Best for aggregations, group-bys, filters, and transformations that don't hold large datasets in memory. Cost per vCPU: ~$0.03/hour (Spot).
• Memory-optimized (r5, r6i on AWS; E-series on Azure): Best for large joins, shuffles, and caching operations that require 4-8 GB of memory per vCPU. Cost per GB: ~$0.01/hour (Spot).
• General-purpose (m5, m6i on AWS; D-series on Azure): Balanced CPU/memory ratio. Default choice when workload characteristics are unknown.

Most ETL pipelines are memory-bound during the join/shuffle phases and compute-bound during the aggregation phases. The practical approach: start with memory-optimized workers (r6i.xlarge or r6i.2xlarge on AWS), run the workload, and monitor memory utilization in the Spark UI. If memory utilization stays below 50%, downgrade to compute-optimized instances. If memory utilization hits 90%+, upgrade to the next memory tier or add more workers.

The cost difference is significant. A 10-node cluster running c6i.2xlarge instances (compute-optimized) costs ~$3/hour on Spot, while a 10-node cluster running r6i.2xlarge instances costs ~$5/hour. If your workload doesn't need the extra memory, that's a 40% infrastructure cost reduction.

Applying Savings Plans and Reserved Instances to Databricks VMs

AWS Savings Plans and Reserved Instances (RIs) provide 30-70% discounts on EC2 compute in exchange for a 1-year or 3-year commitment. The challenge with Databricks: workload patterns shift over time as pipelines evolve, data volumes grow, and teams adopt new tools. Locking in a 3-year RI commitment for r6i.4xlarge instances works until your data science team moves from notebook-heavy workflows to SQL warehouse dashboards, leaving the RI underutilized.

The safe commitment strategy for Databricks infrastructure:

1. Analyze stable workload patterns: Identify job clusters that run daily or weekly with consistent node counts and instance types. These are RI candidates.

2. Start with Compute Savings Plans (AWS) or Savings Plans (Azure) rather than instance-specific RIs. Compute Savings Plans apply to any EC2 instance family/size/region, providing flexibility as workload characteristics change.

3. Commit to 40-60% of baseline compute usage, not peak. Databricks workloads spike during month-end close, quarter-end reporting, or new feature launches. Committing to average usage leaves room for Spot and on-demand to absorb spikes.

4. Reassess quarterly. As pipelines mature, commitment utilization stabilizes. Incrementally increase commitment coverage as workload predictability increases.

Organizations running Databricks on AWS should layer Compute Savings Plans (30-40% discount) with Spot instances (60-80% discount) for worker nodes. The Savings Plans cover the driver nodes and a baseline set of on-demand workers; Spot covers the rest. This hybrid approach captures the deepest discounts without overcommitting.

Storage tiering and egress on the underlying data lake

Databricks reads and writes data to S3 (AWS), ADLS (Azure), or GCS (GCP). Storage costs and egress fees accumulate separately from compute costs, but they're directly tied to Databricks workload behavior. Two optimization levers apply: storage tiering and egress reduction.

Storage tiering: Most Delta tables contain a mix of hot data (queried frequently) and cold data (historical records accessed occasionally for compliance or retrospective analysis). Storing all data in S3 Standard or ADLS Hot tier is expensive. Applying lifecycle policies to transition data older than 90 days to S3 Infrequent Access or ADLS Cool tier cuts storage costs by 50-70% with minimal performance impact, because cold data is rarely accessed.

Egress reduction: On AWS, data transfer directly between Databricks clusters on EC2 and S3 is free within the same AWS Region, including across Availability Zones. Cross-region transfer is charged separately; for example, AWS lists $0.02/GB from US West (Oregon) to US East (N. Virginia). For pipelines that process terabytes daily, egress can add $500-2,000/month to the bill. Mitigating egress:

• Ensure Databricks workspaces and S3 buckets reside in the same region
• Use ADLS regional endpoints when cross-region transfers are unavoidable; don't use S3 Transfer Acceleration as an egress-saving measure, because it adds an acceleration fee.
• Enable Delta table caching on frequently accessed tables to reduce repeated S3 reads

Egress is invisible until it's expensive. Reviewing the CloudWatch or Azure Monitor data transfer metrics monthly prevents surprise charges.

Databricks Cost Optimization on Azure

Azure Databricks shares the same core optimization principles as AWS Databricks—compute type selection, autoscaling, Spot instances—but with a few platform-specific considerations that affect the cost equation.

Azure-specific differences in DBU pricing and VM families

Azure Databricks DBU pricing uses Standard and Premium tiers, but the DBU prices differ slightly from AWS. On Azure Premium, all-purpose compute costs $0.55/DBU, matching AWS, but job compute costs $0.20/DBU (vs $0.15/DBU on AWS). The effective cost difference depends on the VM pricing underneath, which varies by region and instance family.

Azure's VM families map loosely to AWS instance types:

• D-series (general-purpose) ↔ AWS m5/m6i
• E-series (memory-optimized) ↔ AWS r5/r6i
• F-series (compute-optimized) ↔ AWS c5/c6i

Azure Spot VMs offer 60-90% discounts similar to AWS Spot, but eviction behavior differs. Azure provides a 30-second eviction notice compared to AWS's 2-minute notice, giving Azure Databricks clusters slightly less time to reschedule tasks before node termination. For most workloads, the difference is negligible, but latency-sensitive streaming jobs may prefer on-demand workers on Azure.

Azure Reservations and Savings Plans on Databricks workloads

Azure offers Reserved VM Instances and Azure Savings Plans for long-term commitment discounts. Reserved Instances apply to specific VM families (e.g., Standard_E8s_v5), while Savings Plans apply across all eligible compute usage with a dollar-per-hour commitment.

A February 2027 change complicates this: starting February 1, 2027, new Azure reservations for services supported by savings plans will no longer be eligible for exchange; reservations purchased before that date retain one final exchange. Without exchanges, RI commitments carry more risk. The safer path: use Azure Savings Plans (flexible across VM families and regions) instead of instance-specific RIs, especially for Databricks workloads where instance size and family often change as data volumes scale.

Azure Databricks customers should layer Savings Plans at 40-50% of baseline compute usage, then rely on Spot VMs for the remaining worker capacity. This combination captures commitment discounts on the stable workload portion and on-demand flexibility for bursts.

Monitoring and Attribution

Optimization without visibility is guesswork. Databricks and cloud providers offer multiple monitoring and cost attribution tools, but most organizations underuse them. Effective Databricks cost management requires three layers of visibility: granular usage tracking, cost allocation to teams/projects, and anomaly detection.

System tables and cost dashboards

Databricks provides system tables (system.billing.usage, system.compute.clusters, system.lakeflow.job_run_timeline) that log DBU consumption, cluster information, and job execution history. These tables are queryable via SQL in Databricks SQL warehouses or notebooks, enabling custom cost dashboards.

A basic cost dashboard includes:

• DBU consumption by cluster (identifies high-spend clusters)
• DBU consumption by user (identifies which teams drive the most usage)
• Job runtime trends (detects performance degradation over time)
• Idle cluster hours (quantifies waste from forgotten all-purpose clusters)

The Databricks admin console also provides a built-in usage dashboard that aggregates DBU consumption by workspace, cluster, and job. This is the starting point for cost visibility, though it doesn't break down cloud infrastructure costs underneath (EC2, S3, egress).

Cloud cost management tools (AWS Cost Explorer, Azure Cost Management, GCP Cloud Billing Reports) provide the infrastructure-layer view: EC2 instance costs, S3 storage costs, data transfer fees. The gap: these tools don't natively understand Databricks clusters or DBU consumption, so correlating cloud spend with Databricks workload behavior requires joining system table exports with cloud billing data.

Tagging clusters and jobs for chargeback

Tags are key-value pairs (e.g., team=data-science, project=recommendation-engine, environment=production) that attach metadata to Databricks clusters and jobs. Databricks propagates these tags to the underlying cloud resources (EC2 instances, EBS volumes), enabling chargeback: the ability to allocate cloud costs back to the team or project that generated them.

Tagging strategy:

• Required tags: team, project, environment (dev/staging/prod), cost-center
• Enforce via cluster policies: Databricks policies can require specific tags at cluster creation, preventing untagged resources

With consistent tagging, cloud billing exports can group costs by team and project, answering questions like "How much did the marketing-analytics team spend on Databricks last month?" and "Which projects drove the 30% spike in Q4 spend?"

Catching cost anomalies before month-end

Cost anomalies—unexpected spikes in DBU usage or cloud infrastructure spend—often go undetected until the monthly bill arrives. By then, it's too late to remediate. Proactive anomaly detection requires setting up automated alerts based on daily cost trends.

AWS Cost Anomaly Detection, Azure Cost Alerts, and GCP Budget Alerts can trigger notifications when spend exceeds a threshold or grows faster than historical patterns. For Databricks-specific anomalies, query the system tables daily and compare DBU consumption to the 7-day rolling average. If DBU usage spikes >50% compared to the average, investigate: a misconfigured job might be retrying infinitely, or a developer might have left a large all-purpose cluster running.

nOps Optimizes the Cloud Layer Under Databricks

Databricks gives teams strong controls for optimizing DBU consumption, but the infrastructure layer underneath classic compute still lives in AWS, Azure, or GCP. Fully optimizing Databricks spend means connecting workload behavior to the cloud resources and commitments funding it.

That’s where nOps comes in: helping FinOps teams understand and optimize the cloud costs underneath Databricks alongside the rest of their infrastructure.

• Unified visibility: Get all of your spending from Azure, AWS, GCP, AI and SaaS (Databricks, Snowflake, etc.) all in one place, with cost allocation by model, application, customer, or business unit to understand what is driving spend and where optimization will have the greatest impact.
• Commitment Management: Automatically maximize discounts and minimize commitment risk. Customers typically save ~20% by switching to nOps — and with results-based pricing, you pay only when you get better results.

We’ve talked to companies that can save millions on their cloud bills by switching to nOps from competitors. Book a free savings analysis to set up your Databricks cost dashboard and quantify exactly how much more you can save for no work on your part.

nOps manages $4B+ in cloud spend and was recently rated #1 in G2’s Cloud Cost Management category.

FAQ

Let’s dive into a few frequently asked questions about Databricks cluster cost optimization.