How to manage DATABASECHANGELOG growth after generateChangeLog + changelogSync?

General Discussion
1

Hi Liquibase community,

I’m working on a project where we use Liquibase for version control of a PostgreSQL database.

Although we haven’t yet accumulated hundreds or thousands of changesets, I’m describing a hypothetical but realistic future scenario: over time, many projects end up with a long history of changes — including table creation, column updates, functions, procedures, etc.

To prevent new developers or CI environments from having to apply hundreds of historical changesets, we decided to test a baseline (rebase-like) strategy using the following steps:

  1. We used generateChangeLog to capture the current state of the database.
  2. Then we ran changelogSync to mark all the changesets in the generated file as applied.
  3. We created version tags before and after the process (v.YYYYMMDD_HHMM-pre, v.YYYYMMDD_HHMM-post).

This setup worked fine for establishing a clean starting point. However, we noticed that when performing a rollback to the previous tag, the changesets marked via changelogSync remain in the DATABASECHANGELOG table, which raises some concerns:

  • These entries don’t have any actual effect (no rollback logic), but still persist.
  • They clutter the changelog history and may cause confusion during future deployments.
  • If we repeat this process regularly, the table will keep growing with non-actionable metadata.

Specific questions:

  1. Is this expected behavior when using changelogSync?
  2. What is the recommended best practice to manage this situation and avoid DATABASECHANGELOG becoming bloated with irrelevant entries?
  3. Is it acceptable (or advisable) to manually delete those changelogSync-based entries after a rollback, especially if they were never really executed?
  4. How do large-scale teams manage changelog cleanup and baselining? Should older changelogs be archived, or split into separate audit branches?

I’d appreciate any insights or suggestions. The goal is to maintain reliable traceability without making the solution unmanageable over time due to changelog inflation.

Thanks!

2

Hello.

databasechangelog rows created by changelog-sync are indistinguishable from rows created by update, so they should not impact rollback operations at all. I tested and confirmed this with Liquibase 4.31.1 with this process:

  1. Run “update” to deploy all changesets. Confirmed that all rows are correctly inserted in databasechangelog table, and all objects exist as expected. Before tag “v0” is also created and confirmed.
  2. Delete all rows from databasechangelog table.
  3. Run “changelog-sync”. Confirmed that all rows are correctly inserted in databasechangelog table.
  4. Run “rollback v0”, which successfully removes all objects and rows from databasechangelog table, as expected.

There should be no rows in the databasechangelog if you rollback to your before tag. If there are, then there is a problem with your baselining process.

3 Likes
3

Thank you very much for your detailed explanation — it really helped clarify several aspects I was unsure about.

What I was originally trying to do was to generate a tag, then re-run generateChangeLog to capture the current state, and finally run changelogSync without clearing the DATABASECHANGELOG table. My idea was to create a kind of baseline while keeping the previous records, so that I could still rollback to an earlier version if needed.

However, as you rightly pointed out, the entries marked via changelogSync behave the same as those applied via update, and that explains why the rollback didn’t work as expected in my case. Your suggestion to truncate the DATABASECHANGELOG table before re-syncing makes total sense — it creates a clean baseline and avoids clutter or confusion from legacy entries.

The only thing I’d consider adding to your approach is re-generating the changelog after the rollback, to ensure the current state is correctly reflected.

Thanks again for your input — it brought clarity to how to properly manage baselining and keep the changelog traceable but lean. I’ll remain attentive in case there’s anything incorrect in what I described or if you have further suggestions.

Best regards!

2 Likes