Block deployments on drifted databases. Detect out-of-band changes within minutes.
Database schema drift occurs when a live database no longer matches the schema its migrations define because changes were made outside of Atlas. Atlas can detect drift at various points in time and names the out-of-place objects that are found.
A pre-apply check runs at the start of every migration, compares the target against the expected state at the last applied revision, and aborts the deployment before any migration file executes.
Pre-Apply CheckThe same comparison runs outside a deployment, from a cron job or a CI step. It never changes the database, and it exits non-zero when the database has drifted. Its report carries a fingerprint of the drifted state that stays stable while the drift is unchanged, a key for deduplicating alerts.
Background CheckAgent-based monitoring periodically compares a live database against a deployed migration target or another schema, and reports every change it finds.
Schema MonitoringSlack notifications and webhooks fire when the monitor detects drift, with the details attached. The scheduled background check exits non-zero, so a cron job or CI step alerts through whatever already watches it.
Drift NotificationsEvery drifted object is listed with the DDL that reproduces the change, classified as extra, missing, or modified. The Cloud view adds an ERD and HCL or SQL diffs.
Drift ObservabilityInstruct Atlas to ignore objects that live outside the migration scope, such as manually installed extensions, audit tables owned by another service, or a schema owned by another team.
Excluding ObjectsVersioned migrations are fast because they only track which files have already run, then execute the next one in order. They never re-inspect the database, never replan, never diff. By the time a migration breaks, drift has been compounding for weeks.
Before applying any migration files, Atlas makes sure your database wasn't silently changed outside of migrations, a manual ALTER, an emergency hotfix, an ORM auto-migration. If it was, the deploy is aborted and the exact diff is shown so you know what drifted.
The pre-apply check guards the next migration. Continuous monitoring is the radar between deploys, so an out-of-band change surfaces in seconds, not after the next failed deploy.
Production database schema differs from expected state at v20260423120000.
The pre-apply check is the safety belt at deploy time. Continuous monitoring is the radar between deploys. Together they cover the full window in which drift can do damage.
The two highlighted moments show each control catching drift.
Every change in production is either authorized by review, or flagged within minutes.
Atlas covers drift across three dimensions where Liquibase and Flyway leave gaps.
Drift detection runs as a pre-apply check inside the migration pipeline and as a continuous monitoring layer between deploys.
vs. Liquibase and Flyway ship a drift report only. Separate command, no monitoring layer.
Every schema change and every security change. From tables, columns, and views to users, roles, and permissions.
vs. Limited to the schema changes each tool models natively. Security changes (users, roles, grants, RLS) fall outside the diff.
PostgreSQL, MySQL, SQL Server, MariaDB, Oracle, SQLite, ClickHouse, Snowflake, Redshift, Spanner, Databricks, CockroachDB, Aurora DSQL, Azure Fabric, and more.
vs. Coverage varies per database. Many drivers limited or unsupported.
Three steps, no schema rewrite. Atlas reads the database and migration directory you already have, and the check starts guarding the next deployment.
One env block per real environment. The migration directory lives in the Atlas Registry, which supplies the expected state for each applied version that the check compares against.
A check "migrate_apply" block runs the drift check before any migration file. On an existing environment, start with on_error = CONTINUE so the first run reports pre-existing drift in the apply transcript without failing the deploy, then switch to FAIL.
atlas migrate drift runs the same comparison outside a deployment and exits non-zero on drift, so a cron job or a CI step fails without parsing the output. Migration files after the applied version are pending, not drift, and the report counts them as ignored.