What you will be able to do
- Compare serverless, pro and classic SQL warehouses by performance features, startup time and where compute runs
- State when a pro or classic warehouse is the right choice over serverless
- Predict the default warehouse type created from the UI versus the API
- Select the recommended compute for notebooks, job tasks, pipelines and SQL workloads
1.Three SQL warehouse types and their performance features
SQL workloads run on SQL warehouses, and Databricks SQL offers three types: serverless, pro and classic. They differ in two ways. The first is where the compute runs. A serverless warehouse runs on Databricks serverless architecture. For pro and classic, the compute layer sits in your own AWS account. The second is which performance features each type supports:
- Photon is the built-in vectorized query engine. It speeds up SQL and DataFrame calls and lowers the total cost per workload. - Predictive IO speeds up selective scan operations. - Intelligent Workload Management (IWM) uses AI-powered prediction to give workloads the right resources quickly, instead of relying on static thresholds.
Each step down from serverless loses one feature.
| Warehouse type | Photon | Predictive IO | Intelligent Workload Management | Where compute runs |
|---|---|---|---|---|
| Serverless | Supported | Supported | Supported | Databricks serverless architecture |
| Pro | Supported | Supported | Not supported | Your AWS account |
| Classic | Supported | Not supported | Not supported | Your AWS account |
Checkpoint 1 of 6· Match them up
Match each warehouse type to its feature set
Tap a term, then the definition that fits it.
Serverless supports all three performance features. Pro drops IWM. Classic also drops Predictive IO, which is why it gives only entry-level performance.
“A pro SQL warehouse supports Photon and Predictive IO, but does not support Intelligent Workload Management.”Source: docs.databricks.com
Sources1
2.Startup, scaling, and when pro or classic still wins
Startup time is where the types differ most. A serverless warehouse typically starts in 2 to 6 seconds. It scales up rapidly when queries queue, and scales down quickly to minimize costs when demand drops. That makes it the documented choice for ETL, business intelligence and exploratory analysis, especially when query demand varies a lot over time. Pro and classic warehouses typically take about 4 minutes to start. Without IWM, they scale up and down less responsively than serverless.
So why choose anything else? The documentation gives specific reasons:
- Pro: serverless SQL warehouses are not available in your region, or you have custom-defined networking. An example is connecting to databases in your cloud network or on-premises, for federation or a hybrid architecture. - Classic: basic interactive exploration with entry-level performance, when neither serverless nor pro is an option.
No warehouse type supports credential passthrough. Databricks recommends Unity Catalog for governance instead. Lakehouse Real-Time, a Beta serverless warehouse type for sub-second, high-concurrency queries, supports SELECT queries only.
Checkpoint 2 of 6· Check yourself
A company must run SQL queries that federate to a database in its on-premises network over its custom-defined cloud networking. Serverless is available in its region. Which warehouse type does the documentation point to?
Custom networking for federation or hybrid architectures is a named reason to choose pro, even where serverless is available.
“want to connect to databases in your network in the cloud or on-premises for federation”Source: docs.databricks.com
Checkpoint 3 of 6· Exam question
A data engineering team schedules a Lakeflow Job that runs an ETL pipeline once every night and does not need to support interactive notebook use between runs. Which compute configuration minimizes cost for this workload?
Correct answer: B — Configure the job to launch a job cluster, since Databricks automatically terminates it once the pipeline finishes and no idle DBUs accrue.
- A. Keeping an all-purpose cluster running between nightly runs means it accrues DBU cost around the clock even while idle, which is more expensive than terminating compute after each run. All-purpose clusters are meant for shared interactive work, not for minimizing cost on a single unattended nightly job.
- B. A job cluster is provisioned specifically for the job run and Databricks automatically terminates it as soon as the pipeline completes, so no idle DBUs accrue between nightly executions. This matches the requirement to minimize cost for a workload with no interactive use between runs.
- C. SQL warehouses are designed to execute SQL queries against Databricks SQL, not to run a general ETL pipeline defined as a Lakeflow Job task, so this is not the right compute type for the job. Per-query billing does not apply to running a scheduled pipeline task.
- D. A Pro SQL warehouse is chosen when a workload needs custom networking or runs in a region without serverless support, not for minimizing the cost of a nightly ETL job, and it is not the compute type Lakeflow Job tasks run on. Nothing in the scenario indicates a networking requirement.
Sources1
3.Default warehouse type: UI versus API
The default warehouse type depends on how you create the warehouse. This catches people out.
In a workspace whose region supports serverless SQL warehouses, a warehouse created in the UI defaults to serverless. A warehouse created through the SQL warehouses API with default parameters defaults to classic. To get serverless from the API, set enable_serverless_compute to true and warehouse_type to pro. Databricks recommends always setting this field explicitly. (Workspaces that used the API to create a warehouse between September 1, 2022 and April 30, 2023 keep the field defaulted to true.)
If a workspace uses a legacy external Hive metastore, serverless SQL warehouses are not supported. The defaults then fall back to pro in the UI and classic through the API. The same applies to any workspace that cannot use serverless warehouses.
Checkpoint 4 of 6· Check yourself
In a region that supports serverless, an automation script creates a SQL warehouse through the SQL warehouses API without setting enable_serverless_compute or warehouse_type. In most workspaces, what type is created?
The UI defaults to serverless, but the API with default parameters creates a classic warehouse. The exception is a workspace that created a warehouse through the API between September 1, 2022 and April 30, 2023, where the default stays true. That is why Databricks recommends always setting the field.
“Using the SQL warehouses API with default parameters, the default SQL warehouse type is classic.”Source: docs.databricks.com
Sources1
4.Matching compute to the workload
With every compute type covered, the selection rules fit together. For notebooks, serverless compute is generally recommended. Use a serverless SQL warehouse for SQL analytics and reporting. Use classic all-purpose compute only when you need RDD APIs or the R language, because serverless supports neither.
For jobs, you choose compute per task. Serverless is the default for every task that supports it and the recommended choice for most automated workloads. When you use it, you pick performance optimized or standard performance mode depending on your latency and cost needs. Classic jobs compute is for non-SQL jobs that need custom cluster settings serverless does not offer. Classic all-purpose compute should generally be avoided for jobs. It is not optimized for automated workloads, and Databricks does not recommend it for production jobs.
For pipelines, serverless is recommended. Classic pipeline compute is for features serverless does not support, or for working with the legacy Hive metastore.
| Task | Recommended compute | Supported compute |
|---|---|---|
| Notebooks, Python script, Python wheel | Serverless jobs | Serverless jobs, classic jobs, classic all-purpose |
| SQL, dbt | Serverless SQL warehouse | Serverless SQL warehouse, pro SQL warehouse |
| Lakeflow pipelines | Serverless pipeline | Serverless pipeline, classic pipeline |
| JAR | Classic jobs | Classic jobs, classic all-purpose |
| Spark Submit | Classic jobs | Classic jobs |
Checkpoint 5 of 6· Check yourself
A job's SQL task must run on a SQL warehouse. Which of these warehouse types does the jobs task table NOT list as supported for SQL tasks?
SQL and dbt tasks support only serverless and pro SQL warehouses, with serverless recommended. Classic warehouses are not listed.
“Serverless SQL warehouse | Serverless SQL warehouse, pro SQL warehouse”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
Which statement correctly compares features supported across Databricks SQL warehouse types?
Correct answer: C — Serverless SQL warehouses support Intelligent Workload Management, while Pro and Classic warehouses do not support this AI-driven scaling.
- A. Predictive IO is supported on Serverless and Pro warehouses, not on Classic warehouses, so this statement reverses which tier actually gets the selective-scan optimization. Classic is the tier that lacks it, not the tier that has it.
- B. The Photon engine is available across all three warehouse types, so restricting it to Pro alone misstates the feature matrix. Photon acceleration is not a differentiator between Serverless, Pro, and Classic warehouses.
- C. Intelligent Workload Management is a Serverless-only capability that forecasts query demand and manages cluster provisioning automatically, and Pro and Classic warehouses rely on manual or threshold-based scaling instead. This correctly identifies the feature as exclusive to the serverless tier.
- D. Photon is supported on Serverless warehouses as well as Pro and Classic, so excluding Serverless from Photon support is incorrect. Photon availability is not tied to whether the warehouse runs on Databricks-managed or customer-account infrastructure.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A SQL warehouse created through the API is serverless by default, just as in the UI.Why is that wrong?
Only the UI defaults to serverless. The API with default parameters creates a classic warehouse unless you set enable_serverless_compute to true and warehouse_type to pro.
Covered in Default warehouse type: UI versus API
2.Running production jobs on an existing all-purpose cluster is a fine, cost-neutral choice.Why is that wrong?
All-purpose compute is not optimized for automated workloads, and Databricks does not recommend it for production jobs. Use serverless or classic jobs compute instead.
Covered in Matching compute to the workload
3.Pro and serverless SQL warehouses have the same performance features; they differ only in where they run.Why is that wrong?
Pro lacks Intelligent Workload Management, so it responds less well to demand that varies over time and cannot autoscale as rapidly as serverless.
Covered in Three SQL warehouse types and their performance features
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Databricks SQL supports serverless, pro, and classic types.”
↩︎ Three SQL warehouse types and their performance features“A classic SQL warehouse supports Photon but does not support Predictive IO or Intelligent Workload Management.”
↩︎ Three SQL warehouse types and their performance features“the compute layer exists in your AWS account”
↩︎ Three SQL warehouse types and their performance features“Rapid startup time (typically between 2 and 6 seconds).”
↩︎ Startup, scaling, and when pro or classic still wins“Quick downscaling to minimize costs when demand is low”
↩︎ Startup, scaling, and when pro or classic still wins“Serverless SQL warehouses are not available in a region.”
↩︎ Startup, scaling, and when pro or classic still wins“Use a classic SQL warehouse to run interactive queries for data exploration with entry-level performance and Databricks SQL features.”
↩︎ Startup, scaling, and when pro or classic still wins“SQL warehouses do not support credential passthrough.”
↩︎ Startup, scaling, and when pro or classic still wins“Using the UI, the default SQL warehouse type is serverless.”
↩︎ Default warehouse type: UI versus API“If the workspace uses a legacy external Hive metastore, serverless SQL warehouses are not supported.”
↩︎ Default warehouse type: UI versus API“set the enable_serverless_compute parameter to true and warehouse_type to pro”
↩︎ Exam trap 1“A pro SQL warehouse supports Photon and Predictive IO, but does not support Intelligent Workload Management.”
↩︎ Exam trap 3“A pro SQL warehouse supports Photon and Predictive IO, but does not support Intelligent Workload Management.”
↩︎ Checkpoint“A pro SQL warehouse takes several minutes to start up (typically approximately 4 minutes)”
↩︎ Prediction“want to connect to databases in your network in the cloud or on-premises for federation”
↩︎ Checkpoint“Using the SQL warehouses API with default parameters, the default SQL warehouse type is classic.”
↩︎ Checkpoint - 2.
“When you need RDD APIs or R language support.”
↩︎ Matching compute to the workload“For non-SQL jobs that require custom cluster settings not available in serverless.”
↩︎ Matching compute to the workload“Generally avoid. Not optimized for automated workloads.”
↩︎ Matching compute to the workload“when you are working with the legacy Hive metastore.”
↩︎ Matching compute to the workload - 3.https://docs.databricks.com/aws/en/jobs/computeOfficial docs
“Serverless compute for jobs is the default for all tasks that support it.”
↩︎ Matching compute to the workload“Databricks does not recommend this configuration for production jobs.”
↩︎ Exam trap 2“Serverless SQL warehouse | Serverless SQL warehouse, pro SQL warehouse”
↩︎ Checkpoint