BigQuery applies data definition language (DDL) changes with eventual consistency. When Liquibase runs update, it creates the DATABASECHANGELOGLOCK tracking table and then immediately queries it to finish initializing. On a large GCP project, the new table can take longer to become visible to the BigQuery query engine than Liquibase's built-in retries allow, so initialization fails and the command stops before any changesets run.

You are most likely seeing this if update fails during startup on BigQuery after roughly two to three minutes and reports that DATABASECHANGELOGLOCK does not exist, even though the table was just created.

Resolution

The Liquibase BigQuery extension polls for the lock table to become visible before giving up, which resolves this automatically on most projects with no configuration. If your project's propagation delay is longer than the default 120000 ms (2 minutes) wait, increase the total wait by setting liquibase.bigquery.lockTableInitTimeoutMillis to a higher value, in milliseconds:

You can also change how often Liquibase checks for the table while it waits by setting liquibase.bigquery.lockTableInitPollIntervalMillis. For full details on both parameters, see bigquery-lock-table-init-timeout-millis and bigquery-lock-table-init-poll-interval-millis in the reference guide.