Recommendation for managing databasechangelog table for implementing multi-schema database

Liquibase Development
1

I would like to get insight from the community on what others are doing (perhaps best practices) on where the databasechangelog is best located.
Right now, what we can do is create it on the current users schema (place all the changelog to a single schema) or override it with the target schema (each schema will have its corresponding databasechangelog).

I am leaning towards creating the databasechangelog under its corresponding schema . I think it is more manageable for a multi-schema database as well as future proofing in cases where the schema may need to be moved to a different database.

What do you think? What does other teams do using Liquibase in multi-schema environment?

Thanks.

2

Hi @leovic0101

I believe for future proofing various scenarios as you mentioned of moving a schema to other database, having databasechangelog tables created separate would be perhaps the best practice.

Having these tables created completely in a separate schema will users to keep their “managed schema” and “liquibase schema” separate.

I think it completely depends on the use cases users are or would be targetting in future.

Thanks!
Rakhi Agrawal

3

Thanks @rakhi

Yes. I am opting to have the databasechangelog on each schema.

How can I configure this in Liquibase?
My preference is to invoke a single Liquibase command (ie. liquibase update)

4

We run liquibase as the schema user, so the databasechangelog table is created automatically in each individual schema at first liquibase execution.

5

Thanks.
How did you implement it? Is there a native Liquibase solution?
The way I am running it is via shell (bash and Powershell) iterating through each change log.
I am executing this on our CD pipeline.