Databricks — DecisionBox | DecisionBox

Skip to main content<br>Integrations · DatabricksPoint it at Databricks.<br>Walk away with insights.<br>DecisionBox connects to your Databricks workspace in a few minutes — no schema migration, no pipeline to build. The agent reads your Unity Catalog tables in place, runs read-only queries on the SQL warehouse you choose, and surfaces validated insights from what is already in your lakehouse.<br>Get StartedView on GitHub

DecisionBoxagentDatabricksyour workspaceCatalogmainSQL warehouseanalytics_whmain.analyticsRead-only query

Easy and low-effort to integrate<br>Three things to know on day one.

Read-only, scoped by Unity Catalog<br>The agent connects with a Databricks principal you choose — typically a service principal with USE CATALOG, USE SCHEMA, and SELECT on the tables you want it to see. Unity Catalog's permission model is the access boundary; the agent cannot reach anything the principal has not been granted.

Runs on the SQL warehouse you choose<br>Pick the SQL warehouse in the project config via its HTTP Path. The agent runs all of its queries on that warehouse — the type (Serverless, Pro, or Classic), the size, and the Auto Stop you have already set are the cost control. No new compute, no second cluster to manage.

Reads your schemas in place<br>No tables to refactor, no data pipeline to stand up, no warehouse-side changes. Point DecisionBox at a catalog and a schema, and the agent picks up your tables on its first run — and re-checks them on every run after. Metadata is read from information_schema, not from full table scans.

No surprise bills<br>You pick the SQL warehouse. You keep the cost controls you already trust.

Databricks bills SQL warehouses by DBU on the rate of whichever warehouse runs the query. Because the DecisionBox agent runs on the warehouse you point it at — Serverless, Pro, or Classic, whichever size, whatever Auto Stop you've set — every guardrail you have already configured for your dashboards and dbt jobs applies to the agent the same way.<br>Project warehouse config<br>SQL warehouseanalytics_wh<br>TypeServerless<br>Auto Stop10 minutes<br>Catalogmain

Cost ceiling = your warehouse settings

Want a separate line item for DecisionBox runs? Create a dedicated SQL warehouse for the agent, set its Auto Stop and size, and put its HTTP Path in the project config. The agent never sees other compute.

Authentication<br>Two ways in. Both are Databricks-native.

Pick the one that matches how the rest of your Databricks automation already works. Both options end at the same catalog, schema, and SQL warehouse you configured — what changes is how the agent proves it is who it claims to be.<br>Quick startPersonal Access Token<br>Paste a Databricks personal access token in the project config. Stored encrypted, never written to logs. Good for a first run, a proof of concept, or a developer-only project.<br>Same catalog and SQL warehouse boundary as OAuth M2M.

Recommended for productionOAuth M2M (Service Principal)<br>Create a Databricks service principal and an OAuth secret. Paste client_id:client_secret in the project config. DecisionBox uses the OAuth machine-to-machine flow Databricks recommends for any automation that should not depend on a human user's token.<br>Service principal, scoped grants, no personal token in the loop.

Both options end at the same Unity Catalog grants you configured — USE CATALOG, USE SCHEMA, and SELECT on the tables you opted in, plus CAN USE on the SQL warehouse, and nothing more. If your security team has already approved how the rest of your stack talks to Databricks, they have already approved DecisionBox.

Open and portable<br>Open source, and not Databricks-only.

Open source, AGPL v3<br>Every line of the Databricks integration — the PAT and OAuth M2M auth flow, the Unity Catalog metadata reads, the SQL the agent writes — is in the public repo. Anyone can read and audit it before turning it on.<br>View the Databricks provider on GitHub<br>Not locked to Databricks<br>BigQueryRedshiftSnowflakeDatabricksPostgresMSSQL<br>The same agent runs against any of them. If your warehouse moves, your DecisionBox install moves with it.

Keep reading<br>AI Discovery Agents<br>The autonomous loop that writes the SQL in the first place.

How It Works<br>Where the Databricks integration fits in the end-to-end flow.

Setup guide (docs)<br>Field-by-field setup, Unity Catalog grants, PAT vs OAuth M2M.

Try it on your Databricks, in two minutes.<br>Clone the repo, run docker compose up, and point it at a Databricks workspace, SQL warehouse, and read-only service principal. Unity Catalog grants are all the agent ever needs.<br>QuickstartView on GitHub