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)