4 ms·

Database migration is just code. You create your own database migration tool with a incremental version number and you apply it during deployment. You can also

Database migration is just code. You create your own database migration tool with a incremental version number and you apply it during deployment. You can also use a specialized tool. https://datacadamia.com/data/database/migration#tool https://datacadamia.com/data/database/migration#tool Make a branch, test your code and deploy it.

dewey 5y ago
Why would you create your own database migration tool instead of using one of the many existing and bulletproofed tools already?
- mrweasel 5y ago
  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.
  - dewey 5y ago
    > 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.
  - Kaze404 5y ago
    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.
- notreallyserio 5y ago
  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.
unbanned 5y ago
If your company suffers heavily from not invented here syndrome, then sure. But just seems like a waste of time when many tools exist.

dewey 5y ago

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

mrweasel 5y ago
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.
- dewey 5y ago
  > 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.
- Kaze404 5y ago
  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.
notreallyserio 5y ago
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.

unbanned 5y ago

If your company suffers heavily from not invented here syndrome, then sure. But just seems like a waste of time when many tools exist.