Flyway VS roundhouse

Also RedGate, but Flyway has some reasons to recommend it over RedGate Deploy depending on your DBAs/workflows: https://flywaydb.org/

(Though I don't think it is "complete" or "perfect", either.)

EF Migrations are in a really good place now if you like/don't mind C# as a language (and you can easily embed SQL inside the C#, too, but there are benefits to being able to also run high level C# code). With today's tooling you can package your migration "runner application" as a single deployable executable for most platforms. You can build the executable once and run it in all your environments. (The same tool that updates your QA and Staging updates your Prod, testably running the same migrations.) Given the single executable deployable I might even consider using it for projects not themselves written in C#.

There is a bit of tooling needed but is already around. For Java for example I had very good experience with a combination of flyway [1] for migrations, testcontainers [2] for making integration tests as easy as unit tests and querydsl [3] for a query and mapping layer.

[1] https://github.com/flyway/flyway

[2] https://java.testcontainers.org/modules/databases/postgres/

[3] https://github.com/querydsl/querydsl

If you're looking for tools, like https://www.liquibase.com/ or https://flywaydb.org/, which are database-state-based schema migration toolkits - it might be relatively straightforward to build similar ones using Databricks SQL drivers.

Honestly I kind of wish there was a Lukas Eder database migration library. Call it whatever jooq-migration. At least I would have more insight of what is going on (<-- seriously look at the commit history).

This is a 4th option, which should play nice with ArgoCD. The following example runs flyway as a k8s job. The desired migration changes are recorded as files within the chart. This helm chart can be integrated with your application (Using hooks to determine when the migration job is run) or run manually.

By using an opinionated framework within the app/service (like Flyway, Migrate, Diesel, etc). Schema migrations happen on app/service start-up.

Flyway

The grown-up way of creating a database schema is migrations, and no-one ever got fired for choosing Flyway (https://flywaydb.org/), so that's what we'll investigate today. By the end we are able to create the same schema as Exposed was creating, and then, as a second migration, add some constraints to the items table to reflect the reality of our data. And the transition from Exposed to jOOQ is complete!

We use https://flywaydb.org/. You can do the migration before or during service start-up. We do it during.

We just create the greetings table if it does not exist (instead of any database migration library like flyway)

Before we can start using Postgres we need to create a table to store our data. I will be using excellent roundhouse database deployment system to execute database migrations.

https://github.com/chucknorris/roundhouse is interesting, but rougher around the edges.

At my work we use https://github.com/chucknorris/roundhouse

For our projects at work we use sqlserver and use a tool called roundhouse for migrations. https://github.com/chucknorris/roundhouse

Have a look at roundhouse too, if you have SQL experienced people this should be easy to use. All the migrations are basically sql scripts that you can version control. https://github.com/chucknorris/roundhouse