Skippr Docs

Appearance

What to Monitor First After Deploying Databricks as a Warehouse Destination ​

July 2026

A Databricks destination is healthy when the deployed token can write to the intended catalog and schema and any configured SQL warehouse can actually execute the work it is supposed to handle.

Short Answer ​

Monitor the first successful write to the configured workspace_url, catalog, and schema, along with the token and optional warehouse_id that power that write. The destination docs say the token must be allowed to write to the selected catalog and schema, and that warehouse_id matters when you depend on COPY INTO or query execution, so the first healthy signal is a real landed table under the intended Unity Catalog location.

For CDC-managed tables, add one more direct check: confirm that Skippr creates _skippr_order_token and tombstone tables and that one controlled update or delete settles correctly through Unity Catalog MERGE. The CDC destination docs make that final-state contract explicit, so post-deploy validation should go past token validity and into actual merge behavior.

Why Teams Struggle with This ​

Databricks deployments often stop at token auth, but the runtime contract also includes catalog permissions, schema permissions, and sometimes SQL warehouse access if the configured flow uses warehouse_id.

  • A valid token is not enough if it cannot write to the configured catalog and schema.
  • If warehouse_id is set, the SQL warehouse must exist, be reachable, and allow the token to use it.
  • A landed Parquet upload does not prove CDC final-state behavior unless the merge-managed table behaves correctly too.
  • Workspace URL mistakes are easy to miss because they look like generic auth failures at first.

How Skippr Handles It ​

Skippr keeps Databricks deploy checks grounded because the destination surface is explicit. You can test one workspace URL, one token, one catalog, one schema, and one optional SQL warehouse rather than a broad platform state.

The CDC docs add a concrete warehouse invariant on top: once _skippr_order_token and tombstones exist and a sample mutation reconciles correctly, you know the destination is doing the hard part, not just accepting files.

  • Uses a direct Databricks token and workspace URL auth path.
  • Targets Unity Catalog explicitly through catalog and schema.
  • Supports optional warehouse_id checks when the flow depends on SQL warehouse execution.
  • Creates the order-token and tombstone structures needed for CDC final state.

What the First Useful Version Looks Like ​

Start with one small table in the intended catalog and schema so the first write tells you immediately whether the deployment is landing in the right place.

If CDC is enabled, run one controlled mutation after that first load. It is the fastest way to prove that Unity Catalog MERGE behavior is available to the deployment you just put in place.