codd VS goose

Some possible upsides of codd: - No need to manually write verification SQL. Codd will update schema representation files when you codd add some-migration.sql and will compare those to the actual schema when deploying (I'd say in ways which would be very hard to replicate manually, see an example of what codd checks, giving you the option to rollback if they don't match or proceed but log non-matching db objects. - It seems to be much simpler to set codd up. You need 3 env vars to start, a folder to store your migrations and a self-contained statically linked executable. Just codd add migration.sql your way in after that - This might be very wrong as I couldn't find it explicitly documented, but this GH issue suggests it's not so simple to apply all pending migrations in a single transaction with Sqitch? Maybe it requires some bundling or something along those lines and then it's fine, though. In any case, codd will do this automatically when you run codd up (provided postgresql allows it).

In v3.16.0 we added a new Provider feature that unlocks the ability to implement a lot of highly requested features. More details in the blog post:

Next try https://github.com/pressly/goose We have this setup to be run by the CI-CD pipeline to be run before the application is started. BTW, this utility is compatible with https://sqlc.dev , so they work good together.

For database migration I recommend https://github.com/pressly/goose As it works with sqlc and is a powerful tool for complex migrations. This is something a lot of ORMs are really weak with. I was on a large project with Gorm as the ORM and what a nightmare when we pushed to production!

goose https://github.com/pressly/goose - data migration and seed data creation

I'm using .sql migration files with tooling similar to https://github.com/pressly/goose . Is there a way to manage my schema with my pre-existing tooling and my queries/CRUD operations with Ent/Atlas?