Why and when Liquibase?

I have searched for this answer on stack overflow, but I couldn't find any questions on this. I am new to Liquibase and want to learn

• Why Liquibase?
• When exactly one should use Liquibase in the project?

I know that this is to keep all database changes in one place but the similar can be done by creating a simple SQL files in some repository system and keep updating it with time.

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.

Being DevOps Person of my team I would prefer to have all my SQL files at one place i.e. In my SCM (Source Code Management)

Also during CI/CD phase, If the DB Schema gets created along with it, It saves a lot of time and resources. You wouldn't have to have another person managing your database for that client.

ORM like Flyway, Liquibase, EF etc. helps In achieving this.

Having observed liquibase get merged into a medium-to-large project over many months, I offer the observation that developers must serve Liquibase and not vice versa. I understand the use-case, but haven't seen any qualitative improvements in our development process. Our reality is that Liquibase has bogged down our development team with build errors more than anything. Little changes cause big headaches. I respectfully would not recommend its use.

I think is good to add to this topic the concept of Evolutionary Database Design

> Over the last decade we've developed and refined a number of > techniques that allow a database design to evolve as an application > develops. This is a very important capability for agile methodologies. > The techniques rely on applying continuous integration and automated > refactoring to database development, together with a close > collaboration between DBAs and application developers. The techniques > work in both pre-production and released systems, in green field > projects as well as legacy systems.

Here you are the reference of Martin Fowler’s Evolutionary https://martinfowler.com/articles/evodb.html

This is a different approach how to create a design a database That's why Liquibase and Flyway.