What are the DATABASECHANGELOG and DATABASECHANGELOGLOCK tables?

Liquibase creates and manages two system tables in the target database. These tables are the backbone of how Liquibase tracks state and prevents concurrent deployments from corrupting the database.

DATABASECHANGELOG is the audit trail of every applied changeSet. Each row records the changeSet ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, EXECTYPE (EXECUTED or MARK_RAN), MD5SUM (the checksum), DESCRIPTION, COMMENTS, TAG, LIQUIBASE version, CONTEXTS, and LABELS. On every run, Liquibase reads this table to determine which changeSets have already been applied.

DATABASECHANGELOGLOCK is a single-row locking table. Before Liquibase begins applying any changes, it acquires a lock by setting LOCKED=1 along with the hostname and timestamp. This prevents two Liquibase processes (for example, two application pods starting simultaneously in Kubernetes) from running migrations concurrently and causing race conditions. Once migrations complete, the lock is released. If a Liquibase process crashes mid-migration, the lock remains set. You can release it manually with the releaseLocks command or by directly updating the table.

-- Manually release a stuck lock
UPDATE DATABASECHANGELOGLOCK SET LOCKED=0, LOCKEDBY=NULL, LOCKGRANTED=NULL WHERE ID=1;

Both tables are created automatically on the first Liquibase run if they do not exist. They should never be dropped or manually edited in normal operations — doing so can desynchronise Liquibase's view of the database from its actual state.