Databricks

Databricks schema management, done safely

Treat your Unity Catalog schema as code. Extract, compare, and deploy Delta and Iceberg DDL with a per-change safety classifier that reads catalog state, not just the SQL text.

Free tier works forever, offline. No account needed to extract, validate, or generate migration scripts.

Why "CREATE OR REPLACE is safe" has edges

On Databricks, CREATE OR REPLACE TABLE is the recommended way to rebuild a table — a single transaction on the Delta log, history preserved, time travel intact. So engineers internalize "replace is safe, Delta keeps history," and then the state around the statement quietly proves the rule has edges: a managed table whose files get dropped, a streaming reader whose checkpoint is invalidated, an external table that behaves nothing like a managed one.

State-based schema management makes that state visible before you deploy. You declare desired-state .sql files per object and the engine diffs them against the live catalog — so the danger in the state around a statement becomes a mechanical review check, not a memory check.

How DDT works

1 · Extract

Pull a live Unity Catalog workspace into version-controlled .sql files — tables (managed & external), views, materialized views, streaming tables, functions, and more.

2 · Compare

Diff project ↔ built artifact ↔ live account in any direction. Every change lands with a per-field detail of exactly what differs.

3 · Deploy safely

Publish with a safety classifier that refuses data-loss changes unless you pass an explicit gate. Partial-failure rollback included.

The safety classifier knows Databricks

A generic diff tool calls every DROP "destructive" and leaves the judgment to whoever is reading the diff at 5pm on a Friday. DDT classifies each change into four tiers — SAFE, EXPENSIVE, DESTRUCTIVE, UNRECOVERABLE — using Databricks-specific knowledge:

$ ddt extract --target databricks://prod --out ./Lakehouse.ddtproj
$ ddt compare --source ./Lakehouse.ddtproj --target databricks://prod

  ~ TABLE  sales.orders       replace (managed, 2 streaming readers)  [UNRECOVERABLE]
  - TABLE  sales.orders_ext   drop   (external; files retained)       [DESTRUCTIVE]
  + TABLE  sales.orders_v2                                            [SAFE]

  1 UNRECOVERABLE change — publish refused.
  Remediation: SHALLOW CLONE before replace; restart readers from new checkpoint.

Anything destructive or unrecoverable refuses to run unless you opt in explicitly — it is a structural gate, not a comment you scroll past.

Read the deep dives

CREATE OR REPLACE TABLE on Delta feels safe. Here's when it isn't.

Where the Delta safety net ends, what is genuinely unrecoverable, and how to review for it.

Database DevOps: why schema management is stuck in 2015

The gap between application CI/CD and warehouse DDL — and how state-based diffing closes it.

Start free

DDT is priced identically to its sibling. The deterministic core is free forever; Pro and Team add compare, apply-in-CI, and rollback.