- Concept
- Version · 5.0
- User guide
What is the DATABASECHANGELOGLOCK table?
Last updated: August 22, 2026
Liquibase uses the DATABASECHANGELOGLOCK (DBCLL) table to ensure only one instance of Liquibase runs at a time. If the table does not exist in the database, Liquibase creates one automatically.
When you make a database update, Liquibase reads from the DATABASECHANGELOG table to determine which changesets need to run. To avoid conflicts between concurrent updates—which can happen if multiple developers use the same database instance or if multiple servers in a cluster auto-run Liquibase on startup—the DATABASECHANGELOGLOCK table sets the LOCKED column to 1 when an update is currently running. If you make another update during this time, Liquibase waits until the lock releases before running it.
You can control this wait behavior with the following parameters:
Parameter | Default | Description |
| 5 minutes | How long Liquibase keeps retrying to acquire the lock before giving up. |
| 10 seconds | How often Liquibase checks whether the lock has been released while it waits. |
For example, in a cluster where multiple servers might contend for the lock, you might increase the wait time and check less frequently:
changelogLockWaitTimeInMinutes: 10
changelogLockPollRate: 15
The default name of the DBCLL is DATABASECHANGELOGLOCK. You can specify a different name with the --database-changelog-lock-table-name parameter.
Columns
Column | Standard data type | Description |
|
| ID of the lock. There is currently only one lock. |
|
| Set to |
|
| Date and time that the lock was granted. |
|
| Human-readable description of who the lock was granted to. |
Note: If Liquibase does not exit cleanly, the lock row may be left as locked. You can clear out the current lock by running liquibase release-locks which runs UPDATE DATABASECHANGELOGLOCK SET LOCKED=0