Full migration handling workflow?

[StefanBRas]

Hello!

I'm evaluating this as an alternative to Atlas since a lot of their functionality is paywalled.

Right now the workflow is that I make a change to a schema.sql, then atlas generates a timestamped migration. Whenever I start my application it does atlas apply which looks at the migration files and apply all missing migrations (uses it's own in-db schema to keep track of which migrations have been run and which haven't).

It looks to me like all the required functionality to do something similar is provided by pgschema (make a migration, apply the migration) but I'd have to wire it up myself with creating and ordering the migrations and keep track of which to apply and when.

Is this out of scope for pgschema? I think it would make it much easier to migrate to, because you wouldn't have to invent your own workflow.
I work in a monorepo with many migrations and different deployments, so it's not feasible to manually track what migrations to apply

Thanks!

[tianzhou]

You can start by following https://www.pgschema.com/workflow/plan-review-apply first. There are a couple of different workflows.

[StefanBRas]

As I read it, it still requires "manual" work and conventions, with the way you would then name your output files and keep track of which to apply.

I'm not as much asking if it can be done because I'm fairly certain it can, I'm more asking if it's something that you plan or could be persuaded to plan to implement? Maybe I'm very biased because I have that one workflow and I just expected that everybody else will want a similar workflow, but I think it could make adoption much easier because there would be a suggested and opiniated way to use pgschema

[tianzhou]

I don't know exactly what's your workflow is. The best way is to get your hands dirty and try it yourself. Or you can throw your workflow to a coding agent together with pgschema doc.

[StefanBRas]

Right now the workflow is that I make a change to a schema.sql, then atlas generates a timestamped migration. Whenever I start my application it does atlas apply which looks at the migration files and apply all missing migrations (uses it's own in-db schema to keep track of which migrations have been run and which haven't).

So basically

• Make change to a schema.sql
• run atlas migrate migrate diff my_new_migration. This makes a migration file at migrations/<timestamp>_my_new_migration.sql
• push to master
• deploy from master
• application runs atlas migrate apply --dir migrations which looks at all migrations and applies the ones not yet applied

I'll try to make a similar workflow with pgschema :)

But regardless, would you be open for built in and more opinionated workflow or do you mean for pgschema to deliberately be less opinionated and provide building blocks for whatever workflow users want (not mutually exclusive)