Skip to content
Download
Workbook Connect
Databricks SQL Warehouse

Workbook Connect for Databricks SQL Warehouse

Databricks SQL Warehouse runs the queries behind your lakehouse. Workbook Connect puts that data in Excel, where your team can browse a Unity Catalog table, make a change, and commit it straight back.

Download

Your spreadsheet, connected to Databricks SQL

Browse a table, edit a value, and publish it straight back. Excel and your Databricks SQL Warehouse stay in sync, with no exports or copy-paste in between.

EXCELDATABRICKS SQL WAREHOUSE

Lakehouse data, business-friendly editing

Your Databricks SQL Warehouse serves governed tables across the lakehouse. Workbook Connect lets business users read and update the reference and master data they own from Excel, with Unity Catalog permissions and lineage staying fully intact.

Built on Unity Catalog

Connect once and browse your way down: pick a catalog, then a schema, then the table you need. Workbook Connect reads the primary and foreign keys you have declared in Unity Catalog and uses them to set up row identity and lookup columns, so a foreign key becomes a friendly dropdown instead of an ID your colleagues have to memorise. Databricks treats these keys as informational, so they describe your model rather than enforce it, and Workbook Connect uses them the same way.

Serverless or pro, signed in your way

Point Workbook Connect at a serverless or a pro SQL warehouse, whichever your workspace runs. Sign in with a Databricks personal access token, with OAuth, or with Microsoft Entra ID including interactive MFA, so connecting from Excel follows the same rules as every other tool on your lakehouse.

Governed and auditable by Databricks

Every edit runs through your Databricks SQL Warehouse, honoring the access controls, auditing, and lineage you already rely on. Workbook Connect makes no schema changes of its own. It simply makes that governed data reachable from the tool your team knows best.

How your edits are protected

Workbook Connect matches every changed row on its primary key and checks that the values you started from are still the values in the table. If someone else has touched the same row in the meantime, the commit stops and tells you, rather than quietly overwriting their work.

Worth knowing: Databricks has no rowversion or timestamp-style change marker, so the rowversion conflict detection available on SQL Server and Azure SQL Database does not apply here. Primary-key matching is what protects a Databricks commit, which is one more reason to declare primary keys on the tables you plan to edit.

Before you connect

Two things need to be in place on the Databricks side. First, the Databricks ODBC Driver version 2.10 or later, a free download from Databricks. Installing it requires administrator rights, and it has to match the bitness of your Office installation: 64-bit driver for 64-bit Excel, 32-bit for 32-bit Excel. Workbook Connect detects whether a suitable driver is present and links you straight to the download if it is not, so you will never be left guessing.

Second, your tables need to live in Unity Catalog. Workbook Connect relies on Unity Catalog for catalog and schema browsing and for the key metadata behind lookups, so the legacy hive_metastore is not supported.

Common use cases

FAQ

Databricks, answered

Yes, one component: the Databricks ODBC Driver, version 2.10 or later. It is a free download from Databricks. Two things to watch for: installing it needs administrator rights, and it has to match the bitness of your Office installation, so a 64-bit driver for 64-bit Excel and a 32-bit driver for 32-bit Excel. Workbook Connect checks whether a suitable driver is present when you connect and links you straight to the right download if it is not, so you are never left guessing which one you need.

Unity Catalog is required. Workbook Connect uses it to browse catalogs and schemas and to read the primary and foreign key metadata that drives row identity and lookup columns. The legacy hive_metastore is not supported, so tables still sitting there need to be migrated to Unity Catalog before you can edit them from Excel.

Either. Point Workbook Connect at whichever your workspace runs and it connects the same way. Nothing in the configuration changes between the two.

With a Databricks personal access token, with OAuth, or with Microsoft Entra ID including interactive MFA. Whichever you pick, the connection runs as that identity, so a person sees and changes exactly what Unity Catalog already grants them and nothing more.

Primary-key based optimistic concurrency. Workbook Connect matches each changed row on its primary key and confirms the values you started from are still the values in the table, so a row someone else has edited in the meantime is reported back to you instead of being silently overwritten. Worth knowing: Databricks has no rowversion or timestamp-style change marker, so the rowversion conflict detection used on SQL Server and Azure SQL Database does not apply here. That makes declaring primary keys on the tables you plan to edit well worth the effort.

No. Workbook Connect reads and writes rows in tables that already exist. It creates no schema objects, no staging tables, and nothing server-side. Every statement runs through your SQL warehouse as the signed-in identity, so your Unity Catalog permissions, auditing, and lineage cover edits made from Excel exactly as they cover every other client.