Databricks SQL warehouses, AI/BI dashboards and Genie Agents for business users

Part 1 built sales, 1 row per sold order with described columns, and part 2 defined the shop's measures once in the metric view sales_metrics. To start here on Databricks, run part 1's setup_serving.py and sales.sql in a notebook with your catalog and the shop schema selected, then part 2's CREATE VIEW ... WITH METRICS. Everything in this part runs only on Databricks, so it follows Databricks' docs.

The SQL warehouse

Every query an analyst or a dashboard sends runs on a SQL warehouse. There are 3 types:

• Serverless, which Databricks recommends. It typically starts in 2 to 6 seconds, runs in Databricks' account, and its Intelligent Workload Management adds clusters quickly when queries start to queue and removes them when they stop.
• Pro, with its compute in your cloud account, typically about 4 minutes to start. Use it where serverless is not available, or when the warehouse must reach databases on your own network.
• Classic, also about 4 minutes to start, with entry-level performance.

To make one, click SQL Warehouses in the sidebar, then Create SQL warehouse. 3 settings decide what it costs:

• Cluster size sets the compute of 1 cluster, from 2X-Small up. Databricks' advice for serverless is to start larger and size down. If a query's profile shows bytes spilled to disk, the size is too small.
• Scaling sets the least and most clusters, 1 and 1 by default. Clusters are added for concurrency, many queries at once, not to make 1 query faster: Databricks recommends 1 cluster for every 10 queries that run at the same time. If the warehouse's monitoring tab shows Peak Queued Queries above 0 again and again, queries are waiting.
• Auto stop stops the warehouse after so many idle minutes. An idle warehouse keeps charging until it stops. The default is 10 minutes for serverless and 45 for pro and classic.

On Free Edition there is 1 SQL warehouse, limited to 2X-Small, which is plenty for the shop.

Query it from Python

Outside tools reach the warehouse through JDBC, ODBC or a connector. For Python, install the Databricks SQL Connector:

pip install databricks-sql-connector

The warehouse's Connection details tab gives its server hostname and HTTP path. Put them, and a personal access token, in environment variables, never in the code:

"""Ask the SQL warehouse for revenue by country, from the metric view."""
import os
from databricks import sql

QUERY = """
SELECT country, MEASURE(revenue) AS revenue
FROM <catalog>.shop.sales_metrics
WHERE day >= ?
GROUP BY ALL
ORDER BY country
"""

with sql.connect(
    server_hostname=os.getenv("DATABRICKS_SERVER_HOSTNAME"),
    http_path=os.getenv("DATABRICKS_HTTP_PATH"),
    access_token=os.getenv("DATABRICKS_TOKEN"),
) as connection:
    with connection.cursor() as cursor:
        cursor.execute(QUERY, ["2026-10-01"])
        for row in cursor.fetchall():
            print(row)

The ? is a parameter: the connector sends the value apart from the query, so a value typed by a user cannot change the SQL. A query to a stopped warehouse starts it.

An AI/BI dashboard

In the sidebar, click New, then Dashboard. On the Data tab, add the metric view sales_metrics as a dataset. A dashboard applies MEASURE() itself, and shows the metric view's display names, synonyms and formats. On the page, add a visualization and choose, for example, a bar chart with country on one axis and revenue on the other, and a line of revenue by day. Because both read the same measure, the 2 charts always agree with each other and with every query on the metric view.

When it is ready, Publish it, and choose how its queries run:

• Shared data permission, the default: viewers' queries run with your permissions, so they see the charts even without access to sales. Databricks warns that this can expose data to people who were not given it.
• Individual data permission: each viewer's queries run with their own permissions, and they see only what Unity Catalog lets them see, such as the rows module 5's row filters allow.

A published dashboard can be refreshed on a schedule and sent by email to subscribers.

A Genie Agent

Genie answers questions in plain words. A Genie Agent, formerly called a Genie space, is where a data analyst gives it the tables, the metrics and the rules of 1 subject, so business users can ask that subject anything. In the sidebar, click Genie Agents, then New, and choose the data. For the shop, choose sales_metrics and sales. An agent needs a pro or serverless SQL warehouse, and each user's own Unity Catalog permissions decide what data they get.

Databricks' advice for an accurate agent comes in a fixed order:

1. Describe the data. Genie relies on table and column comments, which is why part 1 wrote them. Clear names and descriptions matter more than anything else.
2. Give it fewer, simpler tables. Start with 5 tables or fewer; an agent can hold up to 50. Metric views are especially effective, because they already define the measures, fields and aggregations.
3. Teach with SQL before words. Add example SQL queries for common questions, such as "revenue by country last week", and define terms as SQL. Text instructions are the last resort, and must not contradict the SQL.
4. Test it. Ask the questions your users will ask, correct the SQL it writes, and save each reviewed question as a benchmark to score the agent as it changes.

When an answer comes from a query, Show code shows the SQL Genie ran, so a user who doubts a number can check it. That is also why a fixed definition matters: if "revenue" were a sum someone wrote freshly for each question, 2 phrasings of the same question could give 2 numbers. The text-to-SQLText-to-SQLA model turning a question in plain words into a database query, so people can ask the data directly. It is only as right as its knowledge of the tables and their meaning. concept explains how a model turns a question into SQL, and why it is only as good as what it knows about the tables. Part 4 serves the same table to a partner outside the company.