Liquibase Pro Review
August 18, 2025
Liquibase Pro Review
Score 9 out of 10
Vetted Review
Verified User
Software Version
Liquibase Pro
Overall Satisfaction with Liquibase
Our enterprise database had only one main code base for a long while. That code base was able to handle its own schema changes. However, as we have expanded, we now have multiple applications and services reading and writing to the database. It was no longer practical to use the original code base to manage schema changes. Liquibase has become our centralized schema-management system and has worked very well for us. It is flexible and extensible with a simple and effective design that makes changes easy to track for the DBA. If you are familiar with CLI, the learning curve is small. We now use it to track and apply changes across individual developer database instances, as well as for shared testing and production environments.
Pros
- Liquibase tracks changes in a metadata table contained directly in the target database, making easy administration for the DBA.
- Liquibase handles many validation tests out of the box, making it easy to choose which ones you want to include, with options for writing your own if you choose. This makes it robust and flexible in terms of validation before deployment.
- Liquibase provides easy integration into deployment pipelines for CI/CD. We use it with GitHub for source control and Circle CI for validation and deployment pipelines.
Cons
- One thing that is missing and really needed is tracking of how long a particular changeset took to apply. There is only one date stamp in the metadata table, and it reflects the end time of the changeset command. While most changes run in milliseconds, it is often crucial to know how long it took to create an index, or for a change that locks a table. Right now, I just have to monitor myself. In some cases I can do some rough math based on the Liquibase update report, but only on the run as a whole, not each individual change. Perhaps Liquibase could write a beginning entry to the DATABASECHANGELOG, with a begin time, and then update that entry with an end time when the command has finished.
- The "One change per changeset" policy check isn't robust enough to be adequately used with Liquibase-formatted mySQL changelogs. In mySQL, you must drop and recreate stored logic objects. There is no ALTER option, so either the DROP and CREATE must go into the same changeset (triggering the policy check), or they must be managed in two changesets (meaning two to manage for each logical change). It seems a DROP and CREATE could be made a special case for this policy check.
- We are still in the early phases, where the costs are potentially greater than the benefit. Trying to get Liquibase integrated into a pipeline has taken time investment and required some trial and error.
- We are still a relatively small shop with a relatively small number of schema changes (perhaps 1 every week or so). As such, we aren't at a place where we couldn't have managed control of this without a tool. However, there is no doubt that investing in a tool at this stage was the right move. Now we have established guidelines and a pattern for how to do schema changes in a way that will make things easily scalable as we continue to grow.
Liquibase moved control of our schema out of the code base's ORM and into its own GitHub repository. It also moved the responsibility for database maintenance from the developers to the DBAs. At the same time, Liquibase is easy enough to use that it was a small learning curve for our developers to be able to still propose/submit schema changes for review by the DBAs. It has given us the best of both worlds and streamlined our database administration into one pipeline.
Do you think Liquibase delivers good value for the price?
Yes
Are you happy with Liquibase's feature set?
Yes
Did Liquibase live up to sales and marketing promises?
Yes
Did implementation of Liquibase go as expected?
No
Would you buy Liquibase again?
Yes
Comments
Please log in to join the conversation