What you will be able to do
- Explain why every Databricks SQL query needs a SQL warehouse to run
- Identify the interfaces and external tools that send queries to a SQL warehouse
- Predict what happens when a query is sent to a stopped warehouse, and when to contact an administrator
- Describe how Unity Catalog governs what a query can read when it runs on a warehouse
Key concept
SQL warehouse — The compute that actually runs your SQL. A query in Databricks SQL is just text until it is sent to a warehouse, and the warehouse executes it and returns the results to whichever interface sent it.
1.A query needs somewhere to run
When you write SQL in Databricks, two separate things are involved. One is the query: Databricks SQL describes it as a statement that retrieves or transforms data, and you can save it, version it and reuse it. The other is the compute that executes the query. In Databricks SQL that compute is the SQL warehouse. The documentation defines it simply: "A SQL warehouse is a compute resource that lets you query and explore data on Databricks."
The rule has no exceptions inside Databricks SQL. The SQL editor, AI/BI dashboards, alerts, scheduled jobs, and the ETL that refreshes streaming tables and materialized views all execute SQL, and all of them run it on a warehouse. Notebooks can use one too. Databricks SQL describes notebooks as documents that mix SQL with Python, Scala or R, and says you can "Attach a notebook to a SQL warehouse to run SQL alongside other languages." There is one limit to remember here: notebook attachment works with a pro or serverless warehouse, not with a classic one.
You may also see the term "SQL endpoint" in older material. It is the same thing under an earlier name: the documentation says both terms "refer to a type of SQL-optimized compute resource that powers Databricks SQL," and the rename happened in 2023.
Checkpoint 1 of 5· Exam question
An analyst opens a saved query in the Databricks SQL editor and clicks Run, but nothing executes until they first choose an item from a dropdown menu at the top of the editor. What is that dropdown selecting, and why is it required before the query can run?
Correct answer: A — A SQL warehouse, because it is the compute resource that actually processes the query and returns results to the editor
- A. This is correct: a SQL warehouse is the compute resource that executes queries submitted from the SQL editor, Catalog Explorer, or dashboards, and it must be running (or auto-start) before any query can process and return results.
- B. This is incorrect because SQL editor queries run directly against a SQL warehouse, not a general-purpose notebook cluster, and there is no hidden translation into notebook cells.
- C. This is incorrect because the metastore is attached at the account/workspace level and governs catalog access; it is not something an analyst manually picks per query in the editor dropdown.
- D. This is incorrect because Delta Lake versioning is handled through time travel syntax like `VERSION AS OF` inside the query itself, not through a warehouse-selection dropdown.
2.Where you choose the warehouse that runs your query
Because each query needs a warehouse, every authoring surface asks you to choose one. The warehouses you can use appear in the compute drop-down menus of workspace UIs that support SQL warehouse compute, "including the query editor, Catalog Explorer, and dashboards." Whichever warehouse is selected there runs the statement. You can also click SQL Warehouses in the sidebar to see every warehouse you can use. That list is sorted by state, with running warehouses first, so you can see which ones are already up.
There is usually something to choose from. Most users have access to warehouses that administrators configured, and Databricks also creates a small warehouse called Starter Warehouse automatically, which you can edit or delete. You don't have to pick a warehouse every time, either. You can set a user-level default, and that default "overrides a workspace-level default setting." The options are the workspace default, the last warehouse you selected, or a custom default. You can still override the default for a single query by choosing a different warehouse in the drop-down.
Checkpoint 2 of 5· Put it in order
Put the steps for setting your own default SQL warehouse in order.
- 1.Click Customize your default warehouse.
- 2.Choose Workspace default, Last selected, or Custom default.
- 3.Click the drop-down menu to select SQL warehouse compute.
You open the compute drop-down on an authoring surface, then choose Customize your default warehouse, and then pick one of the three default behaviours.
“Use the drop-down menu to set a new default from any Databricks SQL authoring surface”Source: docs.databricks.com
Queries can reach a warehouse from outside the Databricks UI as well. Databricks SQL supports "many third party BI and visualization tools that can connect to SQL warehouses," such as Power BI and Tableau. Developers can also connect through the Databricks SQL REST API, the SQL Connector for Python, the SQL CLI, and IDE integrations such as DataGrip, DBeaver and VS Code. These tools usually authenticate with a personal access token, which Databricks describes as a credential used to authenticate to the REST API and to connect third-party tools to SQL warehouses. Wherever the query comes from, the warehouse does the same job: it runs the query.
3.What happens when the warehouse is stopped
A warehouse is not always running. The UI shows whether a warehouse is currently running. If a warehouse is stopped, you usually don't need to do anything: "Running a query against a stopped warehouse starts it automatically if you have access to the warehouse." Submitting a query is enough to start the compute it needs.
| Trigger | Where it comes from |
|---|---|
| You attempt to run a query | Any authoring surface, such as the SQL editor |
| A job assigned to the warehouse is scheduled to run | Scheduled jobs |
| A connection is established from a JDBC/ODBC interface | External BI tools and drivers |
| A dashboard associated with a dashboard-level warehouse is opened | Dashboards |
Checkpoint 3 of 5· Check yourself
A warehouse is stopped. Which of these events does NOT appear in the documented list of automatic restart conditions?
Viewing the warehouse list only shows the warehouse's state. Automatic restarts happen when work arrives: a query, a scheduled job, a JDBC/ODBC connection, or opening a dashboard tied to a dashboard-level warehouse.
“A connection is established to a stopped warehouse from a JDBC/ODBC interface.”Source: docs.databricks.com
Restarting and creating are governed by different permissions. Most users "cannot create SQL warehouses, but can restart any SQL warehouse they can connect to." To start a warehouse by hand, you click the start icon next to it in the SQL Warehouses list, which requires at least CAN MONITOR permission on that warehouse. Configuring and launching warehouses requires elevated permissions that are generally restricted to administrators. The documentation therefore tells you to contact an administrator if you cannot connect to any warehouse, if you cannot run queries because a warehouse is stopped, or if you cannot access tables or data from your warehouse.
Checkpoint 4 of 5· Exam question
A BI team wants their nightly dashboard refresh and analysts' ad hoc queries to start executing within a few seconds of being submitted, even after long idle periods, without anyone manually starting compute. Which SQL warehouse type should they choose to meet this requirement?
Correct answer: A — Serverless, because it offers rapid startup of only a few seconds and removes the need to manage underlying cluster infrastructure
- A. Serverless SQL warehouses are correct here because Databricks documents startup times of roughly 2 to 6 seconds and dynamically manage compute, which matches the requirement for fast, hands-off resumption after idling.
- B. Classic warehouses are incorrect because they typically take several minutes to start from a stopped state, which does not meet a requirement for near-instant resumption.
- C. Pro warehouses are incorrect for this scenario because, while they support Photon and Predictive IO, their startup time is also on the order of minutes, and they exist mainly for custom networking or regions without serverless.
- D. An all-purpose cluster is incorrect because Databricks SQL workloads such as dashboards and the SQL editor are designed to run against SQL warehouses, and leaving general-purpose compute running continuously is not the intended or cost-efficient mechanism for this.
4.What a query can read on a warehouse
Running a query requires two things: compute to run it on, and permission to read the data. The warehouse provides the compute, but it does not decide what you may read. "Unity Catalog governs data access permissions on SQL warehouses for most assets," and administrators configure most of those permissions. A warehouse can also have custom data access configured instead of, or in addition to, Unity Catalog. Unity Catalog is enabled by default on new warehouses when the workspace has it enabled.
Checkpoint 5 of 5· Check yourself
A team wants queries on a SQL warehouse to use each user's own cloud credentials through credential passthrough. What does the documentation say?
No warehouse type supports credential passthrough. Databricks points you to Unity Catalog for data governance instead.
“SQL warehouses do not support credential passthrough.”Source: docs.databricks.com
Probably not. The warehouse is supplying compute, since other queries run on it. What you can read is governed separately, mostly by Unity Catalog permissions that administrators manage. Being unable to access tables or data from your warehouse is one of the situations where the documentation says to contact an administrator.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.If a warehouse is stopped, an administrator has to start it before anyone can run a query.Why is that wrong?
Running a query against a stopped warehouse starts it automatically if you have access to the warehouse. Most users can also restart any warehouse they can connect to, even though they cannot create one.
Covered in What happens when the warehouse is stopped
2.A SQL endpoint and a SQL warehouse are different kinds of compute.Why is that wrong?
They are the same SQL-optimized compute resource. SQL endpoints were renamed SQL warehouses in 2023.
Covered in A query needs somewhere to run
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“A SQL warehouse is a compute resource that lets you query and explore data on Databricks.”
↩︎ A query needs somewhere to run“You can also attach a notebook to a pro or serverless SQL warehouse.”
↩︎ A query needs somewhere to run“SQL warehouses and SQL endpoints both refer to a type of SQL-optimized compute resource that powers Databricks SQL.”
↩︎ A query needs somewhere to run“appear in the compute drop-down menus of workspace UIs that support SQL warehouse compute, including the query editor, Catalog Explorer, and dashboards”
↩︎ Where you choose the warehouse that runs your query“Databricks creates a small SQL warehouse called Starter Warehouse automatically.”
↩︎ Where you choose the warehouse that runs your query“Databricks SQL supports many third party BI and visualization tools that can connect to SQL warehouses”
↩︎ Where you choose the warehouse that runs your query“You must have at least CAN MONITOR permissions on the SQL warehouse to manually restart it.”
↩︎ What happens when the warehouse is stopped“Configuring and launching SQL warehouses requires elevated permissions generally restricted to an administrator.”
↩︎ What happens when the warehouse is stopped“Unity Catalog governs data access permissions on SQL warehouses for most assets.”
↩︎ What a query can read on a warehouse“SQL warehouses can have custom data access configured instead of or in addition to Unity Catalog.”
↩︎ What a query can read on a warehouse“Running a query against a stopped warehouse starts it automatically if you have access to the warehouse.”
↩︎ Exam trap 1“In 2023, SQL endpoints were renamed as SQL warehouses.”
↩︎ Exam trap 2“A connection is established to a stopped warehouse from a JDBC/ODBC interface.”
↩︎ Checkpoint - 2.
“Attach a notebook to a SQL warehouse to run SQL alongside other languages.”
↩︎ A query needs somewhere to run“A credential used to authenticate to the REST API and to connect third-party tools to SQL warehouses.”
↩︎ Where you choose the warehouse that runs your query“The compute resource that executes SQL queries. All Databricks SQL interfaces run queries on a SQL warehouse.”
↩︎ Key concept“All Databricks SQL interfaces run queries on a SQL warehouse.”
↩︎ Prediction - 3.
“This overrides a workspace-level default setting.”
↩︎ Where you choose the warehouse that runs your query“Most users cannot create SQL warehouses, but can restart any SQL warehouse they can connect to.”
↩︎ What happens when the warehouse is stopped“If Unity Catalog is enabled for the workspace, it is the default for all new warehouses in the workspace.”
↩︎ What a query can read on a warehouse“Use the drop-down menu to set a new default from any Databricks SQL authoring surface”
↩︎ Checkpoint
Also cited
“SQL warehouses do not support credential passthrough.”
↩︎ Checkpoint