What is the difference between storing a DBUnit database-loadable xml file in version control, and using Liquibase for database version control?

I'm relatively familiar with DBUnit having used it in Matt Raible's Appfuse project, and I've used it for unit testing in projects based on Appfuse. It never crossed my mind before, but it would seem to me that it could also be used for Database version control.

Now Liquibase appears to be used for version control of a database, but I fail to see how another tool is needed for this when you can just pull database changes using DBUnit, and get your data with it as well (storing that file in version control to facilitate your db vcs needs.)

There must be a reason that both of these tools exist, but I can't understand what the difference in scope between them is, could someone please explain this to me?

2 Answers 2


Liquibase is different in that it is mainly focused on ensuring your database schema matches with your current code version. It is not intended to be a diff tool (see http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html) but instead is a way for you to describe the database changes you need made. Liquibase will track which changes have been made to a given database and apply ones that haven't each time it is ran.

Think of liquibase like what is stored in a version control system: a series of patches that can be applied one after another to get from version a to version b. You just need to hand create those patches rather than have them generated by diff like traditional version control systems because with data, how the data changes is as important as what it looks like in the end.

  • How are stored procedures not considered part of the database schema (in that you can't download them from an existing database into your liquibase generated xml file)?
    – leeand00
    Commented Apr 8, 2011 at 13:58
  • 1
    @leeand00 It's mainly an issue of where the coding effort has been put so far. There is a set of schema information that is easily gotten using JDBC metadata, and there is other data that can only be gotten via database specific calls. The current liquibase diff supports reading the JDBC metadata plus a couple database-specific objects, but stored procedures haven't made the list yet. The plan is to extend support to include stored procedures as well, it just hasn't been done yet. Since the diff tools is outside the standard liquibase day-to-day usage, it has taken lower priority. Commented Apr 8, 2011 at 20:40

From their own FAQ: "Can I use DbUnit in order to check and execute DDL statements? No. DbUnit is not intended to track or test structural DB changes. For this purpose check out liquibase."

So it appears that DbUnit is useful for storing data differences between different versions of a database, while LiquiBase is for schema changes.

  • The thing that really confused me about all this is that there doesn't appear to be a way to use LiquiBase to pull an existing database (in it's entirety, including Stored Procs, etc) into the XML file (despite there being a task for creating stored procedures in the database from the changeset).
    – leeand00
    Commented Apr 7, 2011 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.