105

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.

Arun
  • 567
  • 3
  • 12
SSC
  • 2,796
  • 3
  • 24
  • 42

6 Answers6

72

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.

Synesso
  • 34,066
  • 32
  • 124
  • 194
  • 1
    But let's suppose we create a file and write our first script in it and commit it to let's say git. Now, with the time, schema will be updated and we can go back to any interval of time and change back the schema too, no? – SSC Apr 21 '15 at 00:24
  • 1
    With that approach you can _recreate_ the schema, but you can't downgrade/upgrade. The difference is loss of data. – Synesso Apr 21 '15 at 00:26
  • 1
    But the other part, when to use is missing? – SSC Apr 21 '15 at 00:29
  • 1
    Synesso I'm not seeing yet how you can downgrade a production database automatically after it's been in use for a while and decisions have been made on the data using say newly added columns. You can't just drop them now necessarily. Also I don't see why this is better than just a series of versioned SQL scripts kept in source control which include a simple insert into a version table at the start and an update to it at the end to track what's been applied. – Khorkrak Jun 07 '19 at 13:49
  • Another question adding... how can we log the error through email in java. when the SQL changes alter through XML? – UmaShankar Aug 23 '20 at 09:52
19

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.

iCrus
  • 1,090
  • 13
  • 30
  • 4
    Which is me (It gives me the exact impression that you mentioned :P ) +1 for that crucial determination – Ismail Sahin Sep 07 '16 at 21:07
  • you are right, we can keep track of all the changes who made the latest changes and when . if we ned to rool back to a specific point liquibase will be helpful – Anoop P S Oct 16 '19 at 11:43
8

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.

JavaTec
  • 747
  • 10
  • 26
Ted Xu
  • 1,051
  • 1
  • 10
  • 20
3

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.

Bob Barry
  • 103
  • 1
  • 19
    Specs change, new features get added, bugs get fixed. Even assuming "a database is designed to ACCURATELY reflect business relationships", it is normal and expected that you will need to make changes to the DB over time, because businesses and business relationships change over time. Liquibase just helps you manage those changes. That's it. – Steven Byks May 24 '17 at 20:36
  • In my experience very few DBAs and a whole host of developers use Liquibase - I think @bob-barry is spot on with the majority of the end results. DBAs that use tools like Liquibase (or just plain old git for history of changes) will find it useful though. – keba Jan 23 '18 at 01:23
  • Evolutionary DB practices, and agile in general, encourage and enable peer reviews. For a DB with performance needs, DBAs still work with the app teams for DB changes. Tools like Liquibase enable easier refactoring, going against your denormalization argument. 10 years back, I worked for a product installed at 20+ clients, each with their own patch and upgrade cycles. After 2 years of nightmare, and trying to write such tool by hand, we jumped on to liquibase as soon as we learnt about it. And we had tables with 200 M records, not huge for that time either, but something needing DBAs. – user6317694 May 14 '18 at 15:14
  • 3
    I hope to meet you there in heaven some day. Sure sounds nice. – Bijan Jul 18 '18 at 15:39
3

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.

Shikhar Chaudhary
  • 105
  • 1
  • 8
0

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.

Sloka Roy
  • 17
  • 5