Databricks

AddisDB connects to Databricks through the SQL Statement Execution API using a personal access token. Statements run against a SQL warehouse, and long-running ones are polled to completion — so a two-minute query behaves the same as a two-second one.

Who it is for

Databricks is a lakehouse: your data stays as files in object storage, with Delta Lake adding transactions, schema enforcement and time travel on top. The same tables serve SQL analytics, streaming and machine learning without being copied into a separate warehouse.

Delta is Parquet files plus a transaction log, which is what makes those guarantees possible over plain object storage — and also why a table with millions of small files is slow until it is compacted, and why VERSION AS OF can read yesterday’s state without a backup.

Unity Catalog is the other half of the model: three-level naming (catalog.schema.table) and permissions defined once across every workspace rather than per cluster.

It fits data engineering and ML teams who need one platform for pipelines, notebooks and BI, organizations standardizing on open table formats, and anyone who wants to avoid maintaining separate lake and warehouse copies of the same data.

Set up access

1. In your Databricks workspace, open SQL Warehouses and start (or create) a warehouse.
2. Open its Connection details tab and copy the warehouse id — the last path segment of the HTTP path, /sql/1.0/warehouses/<id>.
3. Copy the workspace URL, something like dbc-a1b2c3d4-e5f6.cloud.databricks.com.
4. Under Settings → Developer → Access tokens, generate a personal access token and copy it.
5. Note the catalog and schema you work in — with Unity Catalog, names are catalog.schema.table.
6. Confirm your user has USE CATALOG and SELECT on the schema; Unity Catalog grants are separate from workspace access.

Connect from AddisDB

1. New Connection → Databricks under Big Data / Warehouse. Port prefills to 443.
2. Put your workspace URL in Host.
3. Set Database to WAREHOUSE_ID/CATALOG/SCHEMA — the warehouse id is required, catalog and schema are optional context.
4. Paste the personal access token into the API key / token field.
5. Test, then Save.

# What goes in the Database field
1a2b3c4d5e6f7890/main/analytics

The warehouse id is the id of a SQL warehouse, not an all-purpose compute cluster. A cluster id pasted here produces an authentication-shaped error for what is really a wrong-endpoint problem.

The Big Data Console

Databricks opens in the Big Data Console: catalogs and schemas on the left, a query pane on the right, and a row cap so a preview click never becomes a full scan of a lake table.

Estimate before you scan

Click Estimate cost and AddisDB runs EXPLAIN COST, reading the statistics Databricks annotates onto the optimized plan — the size and row count the query expects to read. You can also open the plan itself when the headline number is not enough.

The estimate is only as good as the table statistics behind it. A Delta table that has never had ANALYZE run against it gives the optimizer little to work with, and the number comes back vaguer than you would like.

Reading yesterday’s data

Delta’s transaction log makes time travel a clause rather than a restore. It is the fastest way to answer "when did this row change" or to compare a table against itself before a pipeline run.

SELECT count(*) FROM sales.orders VERSION AS OF 412;

SELECT * FROM sales.orders TIMESTAMP AS OF '2026-07-30T00:00:00';

DESCRIBE HISTORY sales.orders;

What else AddisDB gives you

• Catalog introspection across catalogs, schemas and tables, plus ⌘K search.
• The full safety model: read-only connections, prod tagging, destructive-statement detection.
• The Chart view for aggregations, notebooks for readable analysis, and AI querying grounded in your real schema.
• Long statements polled to completion, so the editor behaves the same whether a query takes seconds or minutes.