- Track, version and deploy database changes
- Design changes in the format you want (SQL, XML, YAML and JSON)
- Automatically generate database-appropriate SQL
- Active user community and forum
- All the flexibility of Liquibase Community
- Targeted rollback for a specific change
- Targeted rollback for an entire set of changes
- Expanded Stored Logic functionality, including snapshots, diffs and rollbacks
- Easier-to-use changelog
- Break/fix support
- Help for teams to get up and running quickly
- Personalized support from Liquibase experts for your use case
Development teams around the world love Liquibase
Full feature list
All features from community are included with Pro!
- Supports SQL, XML, YAML and JSON formats
- Automatically generates SQL scripts
- Automatically put scripts in order
- Repeatable migrations
- Automatically generate database “diffs”
- Supports context-dependent logic
- Basic rollbacks
- Safe for multiple nodes in parallel
- Manage deployments in each environment with precondition logic
- Ingrates with Maven, Jenkins, Spring, Gradle, Ant and more
- Advanced support and personalized guidance from Liquibase experts
- Targeted rollbacks to undo one change or an entire set of changes
- Expanded Stored Logic functionality, including snapshots and rollbacks
- Easier-to-use changelog
Liquibase Pro Pricing
connected to Liquibase Pro
To purchase more than 25 database connections to Liquibase Pro please contact us.
Frequently asked questions
Liquibased Community is released under the Apache 2.0 license. The main Liquibase jar file also contains commercially-licensed Liquibase Pro code that is only active when a license key is entered.
Liquibase source code is available from the main download page or you can get it directly from Github.
Database connections are simply the number of databases in each environment connected to Liquibase Pro. The illustration below provides examples of how to count database connections.
Liquibase works better because it understands your changes. For example, a database comparison program would simply see the “person” table on integration has a “firstname” and a “lastname” column, but on live, the “person” table has a “name” column. It would report that you need to drop the “name” column and add a “firstname” and a “lastname” column. While this would leave you with the correct schema, you would lose everyone’s name in the process. With Liquibase, you would have a changeset that says “rename ‘name’ to ‘lastname’ and add a ‘firstname’ column” or, even better, “split the name column on a space and place the values in new ‘firstname’ and ‘lastname’ columns, then drop the ‘name’ column.” Knowing why they are different allows you to makes changes to a production database without the fear of losing valuable data.
Yes. Since each change is independent, database changes that have been made in a different branch and then merged in will run the next time you run Liquibase. You may encounter a problem with the order that the statements are in, but any issues you have can be easily solved by reordering the changelog files.
The main reason for using both the author and the id attribute tag is because it is too easy for more than one person to use a tag with the same “id” value–especially when using multiple branches. The source control system is going to resolve and merge two change sets added on different branches, but it won’t care that there are two different changesets with the same “id”, and once a changeset has been run against a database with one id, you can’t easily change it. By also using a unique author tag, the chance of duplicates is much lower.
If an organization does not want to have changes tied back to a particular individual or if the original author isn’t known, you can simply make up a value (such as “UNKNOWN”).
Have more questions? Let us know. Contact us.
Try Liquibase Pro
Liquibase Pro includes more features and support.