Why and when Liquibase?

I have seen liquibase create discipline among the developers when it comes to modifying schema. You just can't go and overwrite other developer's change and execute . Instead, you create your own changeset and add it to the end of sequence of changes to be executed. This also brings in clarity on what change came when and who brought it.

A very "versioned" approach to schema maintainence.

For starters, it does give an impression of "unnecessary work" though.

The key differentiator between a self-managed schema create file and Liquibase (or other schema migration tools) is that the latter provides a schema changelog. This is a record of the schema changes over time. It allows the database designer to specify changes in schema & enables programmatic upgrade or downgrade of the schema on demand.

There are other benefits, such as:

• Database vendor independence (this is questionable, but they try)
• automated documentation
• database schema diffs

One alternative tool is flyway.

You would choose to use a schema migration tool when you want or need to automatically manage schema updates without losing data. That is, you expect the schema to change after your system has been deployed to a long-lived environment such as a customer site or stable test environment.

When you have multiple database instances in dev, qa, production and you want to have a tool to automatically track the change history and apply changes intelligently(apply the diff of current schema and final schema), tools like liquibase or flyway will be very useful.