Hacker News new | past | comments | ask | show | jobs | submit login

Why would you create your own database migration tool instead of using one of the many existing and bulletproofed tools already?



The bulletproofed tools that breaks left and right and often create migrations which results in down time. I haven't used liquibase, but Flyway frequently breaks and migrations often involves downtime, though I'm sure that can be worked around by carefully creating the changes.

The best solution I've seen is to write the migrations by hand, including rollback scripts. This goes for both schema changes and data changes. Schema changes should, in my opinion, be done out of sync with code changes. The new schema is applied first, if that runs for a few days, code can be updated to use the schema. This allows for easier schema and code rollbacks.


> Flyway frequently breaks and migrations often involves downtime

Just as a counterpoint: In my experience with using Flyway in a professional context with big Postgres instances for the past 6 years we never had a single issue with it.


A migration tool doesn't necessarily imply auto generated migrations. Ruby on Rails for example only generates the base file, but you still need to tell it what the migration is supposed to do.


I've yet to find one that will work for my scenario, where I have multiple database systems and (ugh) elasticsearch mappings in play. The tools I have found are all designed for a single system or are so generic I had to write the bulk of the code, anyway.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: