Database Schema Migrations

Point likely stands - any schema migration is not an easier problem on either side - you just move the migration logic to your code instead of the database.

There are various database agnostic schema migration tools that can help. There are rails, django and laravel migrations or alembic if you use python/sqlalchemy. There also pure sql based migration systems such as flyway. There is a great pluralsight course on proper way to do migrations using flyway. Most of it applies to migrations with any migration tool. You might be able to check it out with the free trial. But basically you want to do all your add columns and add tables before deployi

I can't tell if it is for just the schema, or the schema + data inside the tables. If it is just the schema, I feel like there are better software ways to define + manage database migrations (aka make them part of the repo with up/down methods to roll forward / roll back)

How do you handle database schema migrations?

With a tool like this, what's the recommended approach to deal with schema changes (migrations) for my apps/deployments using this db?

Why not just use simple version controlled database migrations, and testing them in a test environment?

What's difficult about schema migration? Not being snarky, genuinely curious :)

How is this different from existing tools such as Flyway or Liquibase?

Interesting. How do you deal with schema migrations?

Sure, I'll throw my hat in the ring here with a shameless self-plug.I help maintain a database versioning/migration tool that my team has been successfully using for years now: https://github.com/nkiraly/DBStewardThe idea is that instead of managing a schema + several migrations, you just store the current schema in XML, then generate a single migration script between any two