Handling Multiple Schemas with Liquibase

Liquibase offers flexibility whether deploying changes to a single schema or multiple schemas. Depending on the database platform, there could even be a use case for deploying changes to multiple databases. An extension of this use case is that multiple schemas - or multiple databases - are shared between multiple teams, that is, multiple teams make changes to the same schemas or databases.

Whether teams are deploying to multiple dedicated schemas/databases - or multiple shared schemas/databases - it is important to pay attention to a few essential items:

• How do SQL script authors write their scripts when their scripts are deploying to multiple schemas - or databases? This typically requires prefixing all objects with the schema name - or the database name.
• Structuring your Git repository for multiple schemas - or databases - so that the Liquibase changelog file can apply the proper deployment recipe and in the correct order.
• When a single team deploys to multiple schemas - or databases - they can structure their application repository by dedicating a directory for database changes.

• When schemas – or databases – are shared across multiple teams, then it is not possible to use each team’s own application repository. This requires setting up a dedicated SQL repository for shared schemas/databases.

We have published best practices for how Liquibase can be used to handle these use cases. These also provide sample changelogs as well as a sample pipeline code, with Liquibase CLI commands, for deploying changes to multiple schemas - or databases.

• Multiple Teams Deploying to the Same Database (Oracle)
• Multiple Teams Deploying to the Same Database (SQL Server)