Track and govern every change for Databricks

Built to fit the stack you already run

Flyway doesn’t replace anything in a Databricks estate, and it doesn’t ask your teams to change how they work.

Unity Catalog governs access: permissions, lineage, discovery. Flyway governs how schemas change, and the two work side by side. dbt keeps your transformations, Terraform keeps your infrastructure, and pipeline-managed Delta tables stay exactly where they are: Flyway deliberately doesn’t touch them. What it covers is the layer none of those tools version, and it does it through the CLI, Git and the CI/CD pipeline you already have.

Every Databricks change, brought under control

Flyway Enterprise puts Databricks changes through the same consistent, version-controlled pipeline as the rest of your estate. Changes are captured as they’re made, checked against your standards, and deployed with a record of exactly what ran.

• Tracked. Object-level version control with a complete history of every change.
• Tested. Policy checks and side-by-side change reports before anything reaches production.
• Recoverable. Generated rollback scripts and drift detection, so a bad change is caught early and reversed cleanly.

It understands the constructs your estate actually runs on

• Unity Catalog schema objects. Schemas, tables, columns, views, stored procedures and constraints, versioned and compared across environments.
• Cross-workspace comparison. See exactly what differs between environments and generate the script that brings them in line.
• Lakebase. Databricks’ transactional layer is Postgres under the hood, and it has no native migration tracking. Flyway supports it today through the Databricks Lakebase (PostgreSQL) project type, so applications and AI agents built on Lakebase get changes tracked and versioned migrations from the first deployment.