TL;DR
A Databricks SQL warehouse is the compute resource that runs SQL queries, dashboards, and BI tool connections against governed lakehouse data. It comes in three production types (serverless, pro, and classic) plus a beta real-time type, scales through cluster size and cluster count rather than a single dial, and bills per DBU of uptime, which makes auto-stop, right-sizing, and workload isolation the three levers that decide what it actually costs you.
Key Takeaways A Databricks SQL warehouse is the compute layer that runs SQL, dashboards, and BI tool queries against Delta tables governed by Unity Catalog, and it holds no data of its own. Serverless warehouses start in 2 to 6 seconds and carry Photon , Predictive IO, and Intelligent Workload Management, while pro drops Intelligent Workload Management and classic keeps Photon only. The $0.70 serverless DBU rate includes cloud instance cost while the $0.55 pro and $0.22 classic rates do not, so comparing DBU rates alone overstates how cheap classic really is. Cluster size fixes slow single queries and cluster count fixes queues, which is why sizing up to clear a queue is the most expensive reflex on this platform. Auto-stop is the largest cost lever available: pro and classic default to 45 minutes, while serverless defaults to 10 minutes and can go as low as 1 minute through the API. Kanerika, a Databricks Consulting Partner, treats warehouse configuration as the final layer of migration validation, after transformation parity and Unity Catalog governance are signed off. The Warehouse Nobody Turned Off A finance dashboard refreshes at 8:05 a.m. every weekday. One analyst opens it, glances at a number, and then closes the tab. The warehouse behind it keeps running for another 45 minutes.
That is not a bug. It is the documented default: pro and classic SQL warehouses ship with a 45-minute auto-stop, and Databricks recommends that value for typical use . Multiply it across a dozen team warehouses, and the bill soon stops tracking query volume at all.
This guide covers what a Databricks SQL warehouse is, how the three types actually differ, how sizing and queuing behave under load, what the compute costs against current list rates, and finally the tactics that reduce spend without slowing anyone down. Every configuration number here was checked against current Databricks documentation in August 2026.
What Is a Databricks SQL Warehouse? A Databricks SQL warehouse is a compute resource that runs SQL queries against data in your data lakehouse . It is the engine behind the SQL editor, AI/BI dashboards, and every Power BI dashboard or Tableau connection that points at Databricks .
The warehouse does not store your data. Tables live as Delta files in cloud object storage inside the Databricks lakehouse architecture , governed by Unity Catalog , and the warehouse reads them on demand. That separation is why you can stop a warehouse entirely, pay nothing for it, and still have every table intact. It also means read performance is set partly upstream, by the clustering and property decisions made when creating tables in Databricks .
Two names cause confusion, so it is worth separating them. Databricks SQL is the product surface: the editor, dashboards, alerts, and query history. A SQL warehouse is the compute that executes statements inside it. You can also have many warehouses under one Databricks SQL experience.
A query then travels a predictable path. A BI tool, notebook, JDBC or ODBC client, or REST call hits the warehouse endpoint. The warehouse checks Unity Catalog permissions, plans the query, scans Delta tables in storage, and returns results along with a query profile you can inspect afterward. That permission step is also where query-time access governance stops being a policy document and becomes an enforced control.
Warehouses also start themselves. A stopped warehouse auto-restarts when a query is submitted against it, when a scheduled job needs it, when a JDBC or ODBC client connects, or when someone opens a dashboard bound to it.
SQL Warehouses Versus SQL Endpoints These are, in fact, the same thing. Databricks renamed SQL endpoints to SQL warehouses in 2023 . Older Terraform modules, blog posts, and API examples still say endpoint, and the API resource path kept its legacy naming for a while, so treat any “SQL endpoint” reference you find as the current object under an old label.
Serverless vs Pro vs Classic SQL Warehouses All three types run the same SQL and read the same tables, so the choice between them is never about SQL compatibility. Instead, they differ in which performance features are switched on, how fast they start, where the compute physically runs, and how they bill.
Serverless warehouses run on compute in the Databricks account, so they start in seconds. Pro and classic warehouses run in your own cloud account, which means you keep network control and pay the cloud provider separately for the underlying instances.
Attribute Serverless Pro Classic Photon engineYes Yes Yes Predictive IO Yes Yes No Intelligent Workload Management Yes No No Typical startup time 2 to 6 seconds About 4 minutes About 4 minutes Where compute runs Databricks account Your cloud account Your cloud account Auto-stop default (minimum) 10 min (5 via UI, 1 via API) 45 min (10 min) 45 min (10 min) List rate per DBU $0.70, includes cloud instance cost $0.55 plus cloud infrastructure $0.22 plus cloud infrastructure
Rates are AWS Premium plan, US East (N. Virginia), taken from the Databricks SQL pricing page in August 2026. They differ by cloud, region, plan tier, and committed-use contract, so treat them as a shape rather than a quote.
The feature rows come from the SQL warehouse types documentation , which also lists a fourth option. Lakehouse Real-Time, or Lakehouse//RT, is in Beta and supports SELECT queries only, so it is a candidate for real-time analytics on Databricks rather than a replacement for a standard BI warehouse.
Reading the DBU Rates Correctly Comparing $0.70 against $0.22 and concluding that classic is three times cheaper is the most common costing mistake on this platform. The serverless rate includes the cloud instance cost, while the pro and classic rates do not.
With pro or classic you also pay your cloud provider for every EC2, VM, or GCE instance the warehouse runs, plus the storage and networking attached to it. So compare total cost of a workload, not the DBU line alone.
Which Type to Choose Databricks generally recommends serverless where it is available, and the platform reflects that. In the UI, for example, serverless is the default in supported regions. Through the API with default parameters, the default is classic unless you set enable_serverless_compute to true and warehouse_type to pro.
That mismatch matters, though it rarely surfaces until the invoice does. A team that provisions warehouses through Terraform or the Databricks REST API and never sets those fields will quietly build a classic estate while assuming it runs serverless.
Three conditions genuinely justify pro or classic.
Serverless is not available in your region yet. Check the current feature region support matrix rather than a third-party list, because availability moves. You need custom networking to reach on-premises or peered databases from the warehouse, which requires compute inside your own cloud account. Your workspace still uses a legacy external Hive metastore, where serverless SQL warehouses are not supported. That is also a reason to plan a metastore migration . SQL Warehouse, Jobs Compute, or All-Purpose Compute? The single biggest source of avoidable Databricks spend is not the warehouse type, but running work on the wrong compute family entirely.
Databricks bills three interactive and batch compute families at very different DBU rates, and the differences compound over a month of scheduled runs.
Compute type Runs Languages List rate per DBU Use it for SQL warehouse Serverless, pro, or classic SQL only $0.22 to $0.70 Interactive SQL, dashboards, BI tool connections Jobs compute Classic or serverless SQL, Python, Scala, R $0.15 classic, $0.35 serverless Scheduled pipelines and transformations All-purpose compute Classic or serverless SQL, Python, Scala, R $0.55 classic, $0.75 serverless Interactive notebooks, exploration, ML development
Rates come from the Databricks Lakeflow Jobs and interactive workloads pricing pages, same plan and region as above.
The pattern to look for is a nightly SQL transformation running on an all-purpose cluster because that is where someone developed it. Moved to jobs compute, the same logic bills at roughly a quarter of the classic all-purpose rate, and the cluster stops the moment the run finishes instead of idling until someone remembers it.
The reverse mistake is subtler, but it costs just as much. Pointing a BI tool at an all-purpose cluster works, so nobody questions it, and you lose Intelligent Workload Management, per-query queuing behavior tuned for concurrency, and the SQL-specific monitoring surface. A Databricks workflow and a dashboard have genuinely different compute needs, so they belong on different compute.
One more boundary: if a warehouse needs to read a system you have not migrated, Lakehouse Federation queries it in place instead of forcing a copy into Delta first.
How Sizing, Scaling, and Queuing Actually Work Warehouse capacity has two independent dials, and confusing them is why so many teams pay for the wrong thing.
Cluster size is vertical, so it sets how much compute one cluster brings to a single query. Sizes run from 2X-Small through 5X-Large, backed by 1 to 512 workers, with driver instances scaling from i3.2xlarge to i3.16xlarge on AWS.
Cluster count is horizontal. It instead sets how many clusters the warehouse can run in parallel to absorb concurrent users. The default is a minimum and maximum of one cluster, and Databricks suggests roughly one cluster for every 10 concurrent queries as a starting estimate.
The rule that follows is simple, though it is almost always ignored. A slow single query is a size problem, while a fast query that sits waiting is a cluster-count problem. Increasing size to fix a queue therefore buys nothing except a bigger idle bill.
Kanerika Service
Databricks Consulting and Platform Engineering
Kanerika is a Databricks Consulting Partner that designs lakehouse architecture, Unity Catalog governance, and SQL warehouse configurations sized against real measured concurrency rather than defaults.
Explore Databricks Services Queuing and Autoscaling Behavior The sizing, scaling, and queuing documentation describes the mechanics precisely, and the thresholds are worth knowing before you tune anything.
A warehouse queues up to 1,000 queries across all warehouse types before rejecting new ones. If a query waits in the queue for 5 minutes, the warehouse scales up. If load stays low for 15 consecutive minutes, the warehouse scales down. Estimated load of 2 to 6 minutes adds one cluster; 6 to 12 minutes adds two; 12 to 22 minutes adds three; beyond 22 minutes adds three plus one more per additional 15-minute increment. Clusters running longer than 24 hours are recycled automatically. On serverless warehouses, Intelligent Workload Management also sits on top of this. It uses machine learning to predict resource needs, then decides what to run immediately versus queue, and watches wait times to trigger upscaling. Pro and classic warehouses, meanwhile, use the threshold logic above without that prediction layer.
A Workload-to-Size Starting Table Databricks documentation deliberately avoids prescribing sizes, because the right answer depends on your data. That is correct and also unhelpful when you are staring at an empty size dropdown, so here is a starting point to test against , not a recommendation to adopt blindly.
Workload profile Starting size Cluster range Auto-stop First test to run Dev and ad hoc SQL, 1 to 5 people 2X-Small or X-Small 1 to 1 5 to 10 min Cold start plus one heavy query Departmental dashboards, under 10 concurrent Small or Medium 1 to 2 10 min Simultaneous refresh of every tile Enterprise BI, 30 to 60 concurrent Medium or Large 2 to 6 10 min Monday 9 a.m. burst replay Heavy single queries over large scans Large or X-Large 1 to 2 10 min Query profile check for disk spill Machine-generated or embedded analytics Small, scaled out 2 to 10 5 min serverless Sustained load with peak queued queries
Note the default nobody expects: when you create a warehouse in the UI, the cluster size Databricks pre-selects is X-Large. Left untouched on a dev warehouse, that is an expensive accident.
Talk to Kanerika
Not Sure What Your Warehouses Actually Cost?
A short working session maps your current warehouse estate against query history, finds the idle spend, and returns a sizing and auto-stop plan you can apply the same week.
Schedule a Demo → What a Databricks SQL Warehouse Actually Costs Warehouse cost is a short formula: DBUs consumed per hour, multiplied by hours the warehouse is running, multiplied by the DBU rate for its type, multiplied by the number of active clusters. For pro and classic, you must also add the cloud provider’s instance bill on top.
Only one of those variables is under daily control, and it is not the rate card. It is running hours.
The table below models list-rate compute spend for a single-cluster warehouse consuming 20 DBUs per hour, across four uptime patterns and 22 business days per month. Treat the DBU consumption figure as the assumption it is; substitute your own from system tables before you budget against it.
Uptime pattern DBUs per month Serverless at $0.70 Pro at $0.55 plus cloud Classic at $0.22 plus cloud 2 hours a day, tight auto-stop 880 $616 $484 $194 4 hours a day 1,760 $1,232 $968 $387 9 hours a day, business hours 3,960 $2,772 $2,178 $871 24 hours a day, never stopped 14,640 $10,248 $8,052 $3,221
Two readings matter more than the absolute numbers. Going from 2 hours to 24 hours of uptime multiplies cost by roughly 16 while query volume may not change at all. And the classic column looks cheapest only because the EC2 bill sits outside it.
Serverless changes this shape rather than just the rate. Because it starts in seconds and scales to zero, a bursty BI warehouse on serverless can genuinely live in the 2-hour row. A pro warehouse with a 4-minute cold start and a 45-minute auto-stop cannot, because nobody will tolerate the wait.
A Cost-Optimization Playbook Six tactics, ordered by how much they typically return per hour of effort.
Tune auto-stop first. Serverless warehouses can go to 5 minutes in the UI and as low as 1 minute through the SQL Warehouses API. On a warehouse that serves scheduled dashboard refreshes, 1 minute is often correct, because the next refresh will start it again in seconds.Right-size downward, not upward. Databricks guidance is to start larger and reduce until performance degrades. Most teams do the first half and then never do the second. Schedule a size review after the first month of real query history.Move scheduled SQL off warehouses. Transformations that run on a fixed schedule belong on jobs compute at a materially lower DBU rate. Reserve the warehouse for interactive and BI traffic, and keep declarative pipelines on their own compute.Consolidate, then isolate deliberately. One shared, scaled-out warehouse generally beats six small per-team warehouses on both cost and queue behavior. Split only where isolation earns it: production BI apart from analyst exploration, and machine-generated traffic apart from both.Tag every warehouse. Warehouse tags are key-value pairs that flow into billing, which is what makes team-level chargeback possible at all. An untagged warehouse is therefore an unowned warehouse.Audit idle all-purpose clusters monthly. They cost more per DBU than a SQL warehouse and are the most common place a forgotten notebook keeps compute alive.Databricks publishes its own cost optimization best practices for the wider platform, and the warehouse-level tactics above sit inside that framework rather than replacing it. Teams that already run Databricks system tables can attribute every one of these levers to a real number instead of an estimate.
Five Anti-Patterns That Quietly Inflate the Bill None of these produce a failed query. That is exactly why they survive for months.
The 45-minute default. A pro or classic warehouse left at its shipped auto-stop bills three quarters of an hour of idle compute after every burst of activity. Ten warehouses, five bursts a day, and idle time soon exceeds query time.
One warehouse per team. Ten X-Small warehouses each idling separately cost more and queue worse than one Medium warehouse scaling to three clusters. Isolation is a real requirement in some cases, but org-chart mirroring is not.
Sizing up to clear a queue. A queue means not enough clusters, rather than not enough size. Doubling cluster size doubles the cost of every query, including the ones that were already fast, and still leaves the queue exactly where it was.
Ignoring disk spill. An undersized warehouse spills intermediate results to disk, and a query that should take 40 seconds takes three minutes. Work through a structured troubleshooting pass and check the query profile for bytes spilled to disk before concluding the SQL is the problem, and check table layout and clustering before concluding the warehouse is.
Machine traffic on a human warehouse. An embedded analytics feature or a reverse-ETL tool generating thousands of small queries will happily consume a warehouse sized for twelve analysts. So give it its own endpoint and its own budget.
Monitoring: The Four Signals That Matter Databricks SQL ships with enough observability that guessing is a choice. Four signals in particular answer most questions.
Peak Queued Queries on the warehouse monitoring page tells you whether concurrency is the constraint. Sustained non-zero values therefore mean raise the maximum cluster count.Query history also separates queue time from execution time. A long total duration with short execution time is a capacity problem, not a query problem.Query profile exposes bytes scanned, joins, shuffles, skew, and bytes spilled to disk. This is also where you learn whether pruning is working.Warehouse uptime against query count is the cost signal. High uptime with low query count is idle spend, so it is the single most actionable number on the page.Statement timeouts are also worth setting alongside these. Warehouse-level statement timeouts are available as a Beta feature through the API, and they stop one runaway query from holding a cluster open.
Connecting BI Tools to a SQL Warehouse Power BI, Tableau, and any JDBC or ODBC client connect using the warehouse’s server hostname and HTTP path, both available on the warehouse’s connection details tab. The same endpoint also serves dbt, notebooks, and the REST API.
Three settings decide whether BI feels fast or frustrating.
Auto-stop against refresh schedule. If dashboards refresh every 15 minutes and auto-stop is 10 minutes, you pay a cold start every cycle. Either shorten the interval between refreshes or accept a longer auto-stop, but choose deliberately.Cluster count against tile count. A dashboard with 20 tiles fires close to 20 queries at once. That is two clusters under the one-per-10 heuristic, not one.Service principals, not personal tokens. BI connections authenticated as a departing employee break the morning after their last day, which is one reason Databricks security design belongs in the warehouse rollout plan.Databricks also maintains dedicated SQL warehouse settings guidance for BI workloads that goes deeper on caching and result reuse. Pair it with Databricks performance optimization work on the table side, because a warehouse cannot outrun bad file layout.
Migrating from Snowflake, Synapse, or Redshift Teams arriving from another warehouse carry sizing habits that do not transfer. Snowflake’s virtual warehouse T-shirt sizes look similar to Databricks cluster sizes but scale differently, and Redshift and Synapse capacity models are node-based rather than per-second.
Watch on YouTube
How to Move Your Enterprise Data Stack to Databricks
Warehouse sizing is the last step of a platform move. This walkthrough covers the sequencing that comes before it, from workload inventory through validated cutover.
A workload-first migration sequence generally avoids most of the surprises.
Inventory legacy queries by complexity, frequency, concurrency, data volume, and required response time. Group them into workload classes before you size anything. Validate correctness before speed. Compare row counts, aggregates, null handling, date logic, and numeric precision between platforms during the same business period. Set acceptance targets per workload class: p50 and p95 execution time, a queue-time ceiling, a refresh window, and a monthly cost ceiling. Run both platforms in parallel against the same periods and log result, runtime, and cost differences rather than reasoning about them. Promote a workload only when correctness, concurrency, recovery, observability, and unit cost all pass, the same gate any data warehouse migration should clear. If you are comparing the destinations rather than the path, our Databricks vs Snowflake and Azure Synapse vs Databricks comparisons cover the platform-level tradeoffs, and Snowflake cost optimization shows how differently the two credit models behave under the same workload.
How Kanerika Approaches Warehouse Design Kanerika is a Databricks Consulting Partner and an ISO 27001, ISO 27701, and ISO 9001:2015 certified data and AI engineering firm working with enterprise teams across banking, healthcare , retail, and manufacturing.
On Databricks engagements, warehouse configuration is treated as the last layer of migration validation rather than the first. Transformation parity, data quality, and catalog governance get signed off first, then warehouse type, size, cluster range, and auto-stop are set from measured concurrency and query shape.
Case Study
Zero-Downtime Databricks Migration for a National Retailer
One of the largest retail corporations in the United States moved business-critical applications off distributed on-premise PostgreSQL and Cassandra databases onto Databricks with zero downtime, decommissioning 100% of the legacy infrastructure and centralizing governance and lineage under Unity Catalog.
Read the Case Study → That order matters because a warehouse tuned against unvalidated pipelines is tuned against the wrong workload. For teams still evaluating the platform, a scoped Databricks proof of concept answers the sizing and cost questions with your own data before any commitment.
Wrapping Up A Databricks SQL warehouse is easy to create and, too often, easy to overpay for. The configuration surface is small, which hides how much of the bill it controls.
Three decisions ultimately carry most of the outcome. Choose serverless unless a region, network, or metastore constraint genuinely rules it out. Then separate the size dial from the cluster-count dial and tune each against the signal that actually points at it. And treat auto-stop as a cost control rather than a convenience setting, because uptime is the variable that moves the invoice.
Everything else is measurement. Query history, query profile, Peak Queued Queries, and warehouse tags will tell you what your estate is really doing, and they will tell you within a week.
Frequently Asked Questions
What is a SQL warehouse in Databricks? A Databricks SQL warehouse is a compute resource that runs SQL queries against data in your lakehouse. It powers the SQL editor, AI/BI dashboards, and every BI tool or JDBC and ODBC client that connects to Databricks. The warehouse stores no data itself. Tables stay as Delta files in cloud object storage governed by Unity Catalog, and the warehouse reads them on demand, which is why a stopped warehouse costs nothing while your tables remain intact.
What is the difference between a cluster and a SQL warehouse in Databricks? A SQL warehouse runs SQL only and is tuned for interactive queries, dashboards, and BI concurrency. An all-purpose cluster runs SQL, Python, Scala, and R, supports custom libraries, and is built for notebooks and exploration. They also bill differently: SQL warehouses list from $0.22 to $0.70 per DBU depending on type, while classic all-purpose compute lists at $0.55 per DBU and serverless interactive at $0.75 per DBU on AWS Premium. Scheduled transformation work usually belongs on jobs compute instead, which lists at $0.15 per DBU for classic.
What is the difference between serverless, pro, and classic SQL warehouses? All three run the same SQL and read the same tables. Serverless runs on compute in the Databricks account, starts in 2 to 6 seconds, and includes Photon, Predictive IO, and Intelligent Workload Management. Pro runs in your own cloud account, starts in about 4 minutes, and includes Photon and Predictive IO but not Intelligent Workload Management. Classic also runs in your cloud account, starts in about 4 minutes, and includes Photon only. A fourth type, Lakehouse Real-Time, is in Beta and supports SELECT queries only.
How much does a Databricks SQL warehouse cost per hour? There is no single hourly figure, because cost is DBUs consumed per hour multiplied by the DBU rate for the warehouse type, multiplied by hours running and active cluster count. On AWS Premium in US East, list rates are $0.70 per DBU for serverless, $0.55 for pro, and $0.22 for classic. The serverless rate includes the underlying cloud instance cost while pro and classic do not, so pro and classic add a separate cloud provider bill for every instance the warehouse runs.
Is a Databricks SQL warehouse serverless by default? It depends on how you create it. In the Databricks UI, serverless is the default in regions where it is supported. Through the SQL Warehouses API with default parameters, the default is classic unless you explicitly set enable_serverless_compute to true and warehouse_type to pro. Teams that provision warehouses through Terraform or the API and never set those fields can end up with a classic estate while believing they run serverless.
What size SQL warehouse do I need? Start from measurements, not from a size chart. Record typical query duration, bytes scanned, peak concurrent queries, and the refresh window your dashboards need. Then match cluster size to single-query weight and cluster count to concurrency, using roughly one cluster per 10 concurrent queries as a starting estimate. Databricks guidance is to start larger and reduce until performance degrades. Note that the UI pre-selects X-Large when you create a warehouse, which is far more than a development warehouse needs.
Can you run Python or notebooks on a Databricks SQL warehouse? No. SQL warehouses execute SQL statements only. Python, Scala, R, custom libraries, and notebook-style development need all-purpose compute, and scheduled multi-language pipelines belong on jobs compute. This is a deliberate boundary: the SQL warehouse is optimized for query concurrency and BI connections, which is also why it carries a different DBU rate and a different monitoring surface from general compute.
What is the difference between a SQL warehouse and a SQL endpoint? They are the same object under two names. Databricks renamed SQL endpoints to SQL warehouses in 2023. Older documentation, blog posts, Terraform modules, and API examples still use the endpoint terminology, and some API paths kept the legacy naming for backward compatibility, so treat any reference to a SQL endpoint as a SQL warehouse described with an outdated label.
