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.

Application Repository for multiple Schemas	Application repository for Multiple Databases

• 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.

Dedicated SQL Repository for Shared Schemas	Dedicated SQL Repository for Shared 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)