Liquibase vs Massive: What are the differences?
Developers describe Liquibase as "Source control for your database". Developers store database changes in text-based files on their local development machines and apply them to their local databases. Changelog files can be be arbitrarily nested for better management. On the other hand, Massive is detailed as "A Postgres-Centric Data Access Tool". Massive's goal is to help you get data from your database. This is not an ORM, it's a bit more than a query tool - our goal is to do just enough, then get out of your way. Massive embraces SQL completely, and helps you out when you don't feel like writing another mundane select * from statement.
Liquibase and Massive can be primarily classified as "Database" tools.
Liquibase and Massive are both open source tools. Massive with 2.55K GitHub stars and 194 forks on GitHub appears to be more popular than Liquibase with 1.78K GitHub stars and 1.09K GitHub forks.
What is Liquibase?
What is Massive?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose Massive?
What are the cons of using Massive?
What companies use Massive?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with Liquibase?
Flyway vs Liquibase #Migration #Backwards-compatible
We were looking for a tool to help us integrating the migration scripts as part of our Deployment. At first sight both tools look very alike, are well integrated with Spring, have a fairly frequent development activity and short release cycles.
Liquibase puts a lot of emphasis on independence with the DB, allowing you to create the scripts on formats like JSON and YML, abstracting away from SQL, which it's also supported. Since we only work with one DB type across services we wouldn't take much advantage of this feature.
Flyway on the other hand has the advantage on being actively working on the integration with PostgreSQL 11, for it's upcoming version 6. Provides a more extensive set of properties that allow us to define what's allowed on what's not on each different environment.
Instead of looking for a tool that will allow us to rollback our DB changes automatically, we decided to implement backwards-compatible DB changes, for example adding a new column instead of renaming an existing one, postponing the deletion of the deprecated column until the release has been successfully installed.