Why and when Liquibase?

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.

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.

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.

I think Why liquibase can be answered if you go through the below article http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html

If you read it carefully the ability to downgrade to a lower version from a higher version with help of simple mvn or CLI commands is very useful which you don't get if you go through the approach of committing your sql file into GIT because then you have to manually run those scripts and also you dont have the change set like :- who did the changes author ,etc.

I believe Liquibase is great when your philosophy is that the database is an afterthought. This philosophy has caused the majority of bad databases in production - and most of them are bad. A database should be designed with a full view of the entire business system, not in pieced by application developers each working in their own silos. The latter method results in work-arounds, denormalized data, poor relationships between tables, duplication of business areas, and an overall messy, high-maintenance-cost system that the client will hate shortly after deployment due to the problems it causes. If a database is designed to ACCURATELY reflect business relationships, its lifespan will be 5 times as long and will serve its purpose 5 times better than one designed in a piecemeal fashion as unfortunately most are.

Liquibase is not a problem in itself but it enables the practice that application developers design the database. THAT is the problem.