What Access Skippr Needs to Write to Databricks

June 2026

Databricks write access is primarily about the token and Unity Catalog grants, not just whether the workspace login works.

Short Answer

Skippr needs a Databricks workspace URL, a personal access token, and permission for that token to write to the selected Unity Catalog catalog and schema. If you set warehouse_id, the SQL warehouse also has to be reachable and authorized for COPY INTO or query execution, because the warehouse becomes part of the actual load path rather than a cosmetic setting.

A clean example is catalog: main, schema: raw, and a PAT in DATABRICKS_TOKEN that can create or update Delta tables there. Skippr can upload Parquet through the Files API, and when you choose the SQL warehouse path, the same identity must also be allowed to use that warehouse for load and CDC reconciliation work.

Why Teams Struggle with This

Databricks often fools teams because workspace access feels like warehouse access. In reality the token, the catalog, the schema, and the optional SQL warehouse are distinct permission checks, and any one of them can stop the write path.

• The PAT must be valid for the intended workspace and not just another Databricks environment.
• The token needs write access to the chosen Unity Catalog catalog and schema.
• If warehouse_id is configured, that SQL warehouse must be usable by the same token.
• CDC uses Unity Catalog MERGE, so the write identity has to support the table updates that MERGE performs, not just file upload.

How Skippr Handles It

Skippr makes the Databricks access model easier to review because it exposes the same concepts the platform uses natively: workspace URL, token, catalog, schema, and optional SQL warehouse. That keeps IAM and warehouse debugging grounded in real Databricks objects instead of in a connector abstraction.

The CDC side is equally concrete. Databricks final-state tables use Unity Catalog MERGE, with _skippr_order_token columns and tombstone tables created automatically, so the write identity has a clear job: maintain the target Delta tables as current state.

• Uploads Parquet files through the Databricks Files API.
• Requires a PAT that can write to the selected catalog and schema.
• Optionally uses a SQL warehouse for COPY INTO or query execution.
• Uses Unity Catalog MERGE with order tokens and tombstones for CDC-managed tables.

What the First Useful Version Looks Like

The first useful version is one workspace, one PAT, one catalog, and one schema that are reserved for raw landing and easy to inspect after a load.

Only add warehouse_id after the token and schema grants already work, because that keeps the first permission review smaller and easier to diagnose.