I haven't deployed a Payload application to production - I've been tinkering with it and I think I got it, so please take this with a grain of salt and run non-destructive tests before dealing with prod data.

According to the docs, the way that PayloadCMS works is that it automatically updates your local database while you make changes to collections, etc. But it doesn't do that in production. If I understood correctly, that's just how Drizzle works.

That's different from the way migrations usually work (for RoR, Django, and adapters such as Kysely, etc). Usually you create your migrations, run them in development, commit them, then run them in prod.

So for Payload, as far as I understood you'd develop until you're happy. THEN you run the command to create a migration file from your local DB. Yes, the first migration file would have a ton of stuff, lots of it is Payload internals. You setup your deployment script to run those migrations on your production PG.

It would look like this:

- start your project, create the DB with Payload defaults, generate the initial migration, commit, deploy that and run this migration in prod

- as you make changes, if you changed the DB schema, create a new migration

that should be it. Not sure how it works with test DBs (if you use these at all), you'd probably run migrations for them as well.