I've found Liquibase [1] to be really good for this, although the docs don't give much of a hint about how to structure your change sets. If you get it right,

I've found Liquibase [1] to be really good for this, although the docs don't give much of a hint about how to structure your change sets. If you get it right, it's really easy to manage the DB schema structure and commits to your source repository are very legible (because there's one file per entity being modified), much better than interleaving all changes in a single stream IMO. Particular highlights: - Their annotated SQL format allows you to create a file per table that contains a first "changeset" to create the table and subsequent changesets for each alteration - The "runOnChange" option allows idempotent, non-data-destroying parts of your schema such as view and function definitions to be kept as individual files and modified in place (Liquibase uses a hash of the definition to decide whether to rerun it when migrating) - The "includeAll" tag lets you collect together the scripts in directories ("/views", "/tables", "/functions", etc.) and have them automatically picked up and run from a single "schema.xml" file in the root. [1] http://www.liquibase.org http://www.liquibase.org