MySQL Version Control – Subversion

Wondering if it is possible to have a version control of a MySQL database.

I realize this question has been asked before however the newest is almost a year ago, and at the rate things change…

The problem is coming that each developer has apache/MySQL/PHP on their own computers to which they sometimes edit the database. Its rather inconvenient if they have to send an email to all the other developers and then manually edit the test servers database.

How do you deal with this problem?



Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

This is not a MySQL-related solution in itself, but we’ve had a lot of success with a product called liquibase. (

It’s a migration solution which covers many different database vendors, allowing all database changes to be coded in configuration files, all of which are kept in Subversion. Since all configuration is kept in XML files, it’s easy to merge other people’s changes into the mainline script and it plays well with tags and branches.

The database can be brought up to the current revision level by running the “update database” command. Most changes also have the ability to roll-back a database change, which can be helpful too. I would recommend following the practice of making sure you get current before running the migration, as this would likely be easiest.

Finally, when it comes to a production delivery, you can choose to have all the database changes output as a full SQL script so it can allow DBAs to run it and maintain a separation of duties.

So far, it’s worked like a charm.

Method 2

Well we use Rails which keeps all the change in the migration files. I know that a couple of PHP frameworks do the same thing – Symphony for instance. So when all the changes are merged in our repository ( we user mercurial) – we can see all the changes in migrations that need to or were applied on database in development. Than the person responsible for production rolls out code to production after a full backup is made. However if you don’t use a PHP framework that takes care of this than, awied’s suggestion sounds very interesting – I haven’t heard of liquidbase before but I will definitely check it out.

Method 3

There is a tool called iBatis, now called MyBatis that handles versions of databases perfectly.

It takes a little work to have all your changes in script instead of with a graphical tool, but, if you are familiar with coding, it’s not a problem.

When you have multiple databases (like dev-test-prod), you just make 3 environment files and you can update one environment with only one command-line instruction.

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x