Nobody can quote you a price. We can tell you where it leaks.
Databricks bills consumption: no seats, no suite, no up-front cost, measured per second. Rates differ by product, by region and by cloud, which is why any figure quoted without all three is fiction. What can be said usefully is this — in every over-spending platform we have audited, the cause was not the rates. It was five or six settings, each of which is a configuration change rather than a rewrite.
Five things you will see on an invoice.
Worth learning, because an invoice you cannot read is an invoice you cannot challenge.
A normalised unit of processing power, driven by the compute resources used and the data processed. The rate per DBU differs by product — data engineering, warehousing and AI are priced on separate lists — and by region and cloud. This is the line that dominates most bills.
A standardised measure of storage usage, whose value varies by region, storage type, data volume or transactions. Separate from, and in addition to, what your cloud provider charges you for the bucket.
Used for data transfer and networking charges, defined as 230 bytes. Small until it is not — regular large cross-region or outbound transfers are worth modelling before they appear.
Billed by hours provisioned, rounded up to the whole hour. A fixed cost of a network choice rather than of a workload, which means it does not go away when nothing is running.
The granularity of consumption billing, and the reason serverless compute that idles to nothing changes the economics of bursty work so sharply.
Who sends the invoice, and what is not on it
Pay-as-you-go accounts are billed monthly to a card on file, and charges may be taken more often as they accrue. Azure Databricks is billed by Microsoft under your Azure subscription, which matters for anyone with an existing Azure commitment to draw down.
Storage, networking and cloud infrastructure costs are separate and come from your cloud provider. A Databricks estimate that does not include them is incomplete, and the gap is not small.
Discounts exist. Earn the right to take one.
Databricks offers committed use contracts, with greater benefits at larger commitments, including the option to apply a commitment across more than one cloud. Temporary promotional discounts appear on the price list or are communicated to eligible customers — whether those stack with a commitment is not stated publicly, which is itself a question to ask.
The mistake we see most often is committing before the workload is understood. A commitment made on an estimate is a bet on an architecture nobody has measured yet, and the downside is paying for capacity you were persuaded to promise. There is a second mistake, quieter and more common: committing to the right number for a platform that has not been tuned, so every configuration leak you have not found yet is inside that commitment, on a multi-year term rather than a monthly one.
Our advice is unglamorous: run pay-as-you-go for a quarter with proper tagging, fix the configuration leaks below, and then commit to a number you can defend from your own usage data. You will commit to less and get a better outcome, because the leaks you fixed were going to be inside the commitment otherwise.
- 1
Measure
A quarter of real usage, tagged by team and by workload, before anyone signs anything.
- 2
Fix
The configuration leaks below, before they are baked into a commitment for three years.
- 3
Commit
To a defensible number, drawn from your own usage data rather than from a projection.
Six settings, in the order we find them.
This is the most useful thing on this page. None of these is a rewrite, none requires a new architecture, and together they routinely halve a bill — which is why we audit them before anyone argues about rates.
| What we find | Why it costs | The change |
|---|---|---|
| Nightly work on all-purpose compute | All-purpose compute is meant for interactive work and is shared and restartable. Scheduled work running on it pays interactive rates and often keeps a cluster alive between runs. | Move it to job compute, which the scheduler creates per run and terminates afterwards. |
| Clusters with no auto-termination | Somebody started it on Thursday to look at something. It is Tuesday. This is the single most common finding, and the most embarrassing one to explain upward. | Set auto-termination as a policy rather than a habit, and review long-running clusters weekly. |
| Classic warehouses where serverless would idle | BI load is bursty. A classic warehouse running through the quiet hours bills for the quiet hours. | Serverless, which Databricks recommends where available — unless a stated requirement needs the compute in your own account. |
| Dashboards scanning raw history | Every open recomputes three years of events for a chart that needed a maintained summary. Multiply by the number of viewers and the number of opens a day. | Materialized views that refresh incrementally, with the definition in the catalogue. |
| Pipelines re-reading the world | A full extract every night, because nothing captures change. The cost is paid twice — in compute here and in load on the source system. | Change-data capture through a managed connector, or the change data feed. Lakeflow → |
| Dedicated model serving endpoints, idle | A custom or provisioned-throughput endpoint bills its own dedicated serving compute whether it is busy or not. Batch work pointed at one pays for the gaps. | For batch inference, use Databricks-hosted models rather than a provisioned endpoint — which is Databricks’ own guidance. |
A seventh, which is not a setting but a decision: ingesting everything “because we might need it”. Storage is cheap and the pipelines, the optimisation and the governance around unused tables are not. Select tables deliberately, and revisit what nobody has queried in six months.
Which features add a charge, and which do not.
The difference between a predictable platform and a surprise is knowing this list before someone discovers it in an invoice. The compute running a query is always billed; these are the additions.
Budget for these separately
- Task-specific AI functions and Databricks-hosted model endpoints, which add inference charges on top of compute.
ai_query, billed according to the model serving endpoint you name.- Custom and provisioned-throughput endpoints, billing their own dedicated serving compute.
vector_search, billed through the AI Search service.- Private connectivity endpoints, billed by hours provisioned.
Compute only
ai_forecast,ai_detect_anomalies,ai_predict_class,ai_predict_valueandai_top_driverscarry no separate inference cost.- Unity Catalog, included in the Premium and Enterprise tiers — you pay only for compute and storage.
- AI/BI dashboards and Genie spaces, with no per-seat or per-licence BI fee.
Spend is queryable: batch inference from some functions appears under MODEL_SERVING in system.billing.usage, and others under AI_FUNCTIONS. That distinction is how you attribute AI spend to a team instead of arguing about it. One exception to flag: Genie One pricing has been announced twice with different dates, and that is worth resolving in writing before a large rollout.
Attribute first. Then limit. Then review in public.
Platforms do not become expensive because of rates. They become expensive because the bill arrives somewhere nobody can recognise their own work in it, so nobody feels responsible for any of it.
Tag everything, from day one
Compute, jobs, warehouses and endpoints tagged by team and by workload. Retrofitting attribution is painful and always incomplete, and six per cent untagged is enough to make a review arguable.
Make the system billing tables the single source
Not a spreadsheet, not the portal, not an export. One query everyone trusts, which also means the finance team and the platform team stop maintaining two versions of the truth about cost.
Set budgets with hard caps for AI
Unity Gateway supports budgets with monitoring, per-user thresholds and hard caps, plus rate limits on model and MCP services. One retry loop in one notebook can otherwise spend a month of budget overnight. Unity Gateway →
Put cost beside governance
The governance dashboard shows cost alongside access changes and policy drift. Seeing the three together is how you notice that the expensive new workload is also the ungoverned one.
Review monthly, with names on it
Each team sees its own number, in a meeting, with its own people present. This is the control that works, and it is the one most organisations skip because it is social rather than technical.
A platform nobody is accountable for the cost of will cost whatever it costs. Attribution is not an accounting exercise, it is the only thing that makes the engineering decisions visible.
What we say in the first week of every engagementFree Edition is for learning. Be clear about that.
There is a Free Edition and there is a trial of the full platform with credits. They are different things and only one of them will tell you anything about cost.
Free Edition is genuinely good for what it is: learning the interface, the SQL, the notebooks, the catalogue. It is also deliberately boxed in, and knowing the walls saves a wasted fortnight. Some limits can be raised after identity verification through LinkedIn; the enterprise-only features and the administrative restrictions stay.
The trial gives free access to the full platform, with credits whose amount and eligibility Databricks decides, ending when the credits are used. If you connect it to your own cloud account, your cloud provider still charges for what you use. At the end of a trial you are subscribed automatically to the plan you were using, and a valid payment method is required to continue — so put a date in the diary.
What we usually recommend instead
Learn on Free Edition, and run a short paid proof on your own data to find out what your workload actually costs. A fortnight of real usage with proper tagging answers the pricing question definitively, and nothing else does.
One small warehouse
One SQL warehouse at 2X-Small, serverless only, no custom compute configurations and no GPUs. Jobs cap at five concurrent tasks; one active Lakeflow pipeline per pipeline type.
One search endpoint
One AI Search endpoint with one search unit and no direct vector access, limits on active serving endpoints, no GPU serving. One Lakebase project, scaling to zero.
One app, time-limited
The AWS documentation says one app per account running up to 24 hours after being started, updated or redeployed; another localised page says three. Check the current English page.
A real list, worth reading
R and Scala, custom workspace storage, online tables, clean rooms and Agent Bricks are not available. Nor are Lakebase database instances.
One workspace, no SSO
One workspace and one metastore per account, no account console, authentication limited to email one-time codes and Sign in with Microsoft — no SSO, no SCIM.
Not for commercial use
Free Edition accounts may not be used commercially, and are not covered by the support policy or any SLA. Exceeding a quota can make compute unavailable until it resets, though data is not deleted.
The three places cost is actually decided.
Not on this page. In the compute you choose, the pipelines you run and the AI you point at an endpoint.
Lakehouse
SQL analytics on Delta Lake and Apache Iceberg tables in your own cloud storage, with serverless compute, self-tuning layouts and a real-time tier for dashboards and apps.
Read it →Data engineeringLakeflow
Managed connectors that capture change from your source systems, declarative pipelines that run the same code for batch and streaming, and one scheduler over the lot.
Read it →Artificial intelligenceAgent Bricks
A runtime for agents that survive a crash, memory and sessions, tools and MCP servers, search over your documents, traced runs and evaluation by judges and by your experts.
Read it →Where this leads next.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
What people ask about the bill.
How is Databricks actually billed?
By consumption, measured per second, with no up-front cost on pay-as-you-go. Compute is counted in DBUs — a normalised unit of processing power that varies by the compute type and the work done — and storage in DSUs, whose value varies by region, storage type, volume and transactions. Data transfer is billed per GB and private connectivity endpoints by the hour, rounded up. Your cloud provider bills its own infrastructure separately, and Azure Databricks is billed by Microsoft under your Azure subscription.
Rates differ by product, by region and by cloud, which is why nobody can quote you a figure without knowing all three.
Can we get a discount?
Yes: Databricks offers committed use contracts, with better terms at larger commitments and the option to apply a commitment across more than one cloud. Temporary promotional discounts appear on the price list or are communicated to eligible customers; whether they stack with a commitment is not stated publicly.
The mistake we see is committing before the workload is understood. Measure for a quarter, then commit to a number you can justify.
Where does the money actually leak?
Rarely where people look. In our experience the recurring causes are: all-purpose compute left running for work that should have been a job; classic warehouses where a serverless one would have idled to nothing; dashboards querying raw history instead of a materialized view; pipelines re-reading the world because nothing captures change; and batch AI functions pointed at a dedicated serving endpoint that bills whether it is busy or not.
Each is a setting, not a rewrite. Together they routinely halve a bill, which is why we audit them before anyone argues about rates.
Which products bill on top of compute?
Several, and knowing which is the difference between a predictable platform and a surprise. AI functions always bill the compute running the query, and task-specific functions and Databricks-hosted model endpoints add inference charges — ai_query bills according to the serving endpoint you name, and custom or provisioned-throughput endpoints bill their own dedicated compute. Vector search bills through the AI Search service. Forecasting and prediction functions carry no separate inference cost.
Usage is queryable in system tables, which is how you attribute spend to a team instead of arguing about it.
How do we keep control once more teams are on it?
Attribute first, then limit. Tags on compute and jobs, the system billing tables as the single source of truth, budgets and per-user thresholds with hard caps through Unity Gateway for AI usage, and a governance dashboard that shows cost beside access changes and policy drift.
The cultural half matters as much: a monthly review where each team sees its own number. Platforms get expensive when the bill arrives somewhere nobody recognises their own work in it.
Send us thirty days of usage.
If you are already on Databricks, give us a month of system billing data and we will come back with the configuration changes worth making, each with the saving attached and none of them a rewrite. If you are not on it yet, we will tell you what a measured proof would cost before anyone commits to anything.
- Findings from your own usage tables
- Configuration changes, not re-architecture
- Each saving quantified and attributed
- Tagging and budgets put in place
- A monthly review each team can see itself in
Databricks, Lakehouse, Lakeflow, Lakebase, Unity Catalog, Genie, Agent Bricks, OpenSharing, Delta Sharing and Lakewatch are trademarks of Databricks, Inc. Apache, Apache Spark, Apache Iceberg and Spark are trademarks of the Apache Software Foundation. Delta Lake and MLflow are projects of the Linux Foundation. SAP, SAP Business Data Cloud and SAP Datasphere are trademarks of SAP SE. PostgreSQL is a trademark of the PostgreSQL Community Association. All other names belong to their owners. Mawkish Technologies is not affiliated with, endorsed by or a reseller for Databricks, Inc. Everything described here is taken from material Databricks publishes; product names, availability and prices change, so check the current documentation before you commit to anything. Screens shown are our own illustrations with sample data, not screenshots.
At Mawkish, the Ulmholm Review is how we keep Databricks Pricing and Cost work checked, owned and answered for, whoever does the build.