The pain that I've often felt when creating database migration files, is best described in this Speakerdeck: Sane Database Change Management with Sqitch.

  • Paste entire function to new "up" script
  • Edit the new file
  • Copy the function to the new "down" script
  • Three copies of the function!

And I end up with no clear diff of the function that I can easily git-blame to understand the change later in time.

I feel too that

sync-based approach to schema migrations is much better.

I stand before this new greenfield project (as the only developer). The stack I've chosen is Postgres (on AWS RDS), Node.js, Express, Apollo (GraphQL) and React (on Heroku).

I have read about sqitch and migra, but never used them. Are those the cure to the pain I've felt? Are they compatible with the stack I'm using for this new project or what other sync-based migration tool is best compatible with this stack?

My current workflow is like this. Dev and production database models are the same. A new story arrises. An existing database function needs to be altered. I create a new migration file. I copy the function that needs to be altered into the "up" and again into the "down" part of the new migration. I commit. I alter the "up" part. I commit (creates diff).

This all feels very verbose just when only a few lines in the function needed to be changed. Ideally, I have the whole schema in code in git. I alter the schema. I commit (creating a diff in git history). A tool then helps to generate the required SQL statements and makes a new up and down migration file for me. I don't mind that I need to verify the generated migration file.

  • can you explain what the pain is more clearly? the way I do db migration is with vs schema compare and db projects
    – Ewan
    Jan 17, 2019 at 15:44
  • I'd be interested to see where you are 2 years on... Still using this process? Nov 15, 2021 at 5:01
  • 1
    There is also liquibase, which I cannot fully endorse, but it does its work. Then you can immediately see the author, diff the XMLs etcetera.
    – Joop Eggen
    Nov 15, 2021 at 9:16
  • Another option is FlyWay.
    – Laiv
    Nov 10, 2022 at 13:54

1 Answer 1


I think the short answer is. Yes, the way you think it should be done is the normal way to do it.

Sure you need to save your migration and roll back scripts, but you dont use source control for that. They are in databases or separate files with ordered filenames.

  • 7
    While it is true that migrations/rollbacks should not change once created, and therefore don't get any direct benefit from a VCS in terms of their file content; it can often make sense to store them in a VCS alongside the codebase, so that the specific version of the codebase inherently contains the specific migration/rollback scripts that match the state of the codebase.
    – Flater
    Jul 13, 2022 at 7:40

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.