Workflow for Payload 3.0 + Drizzle/Postgres in a Team

[vapid hawk]

Hi all! We’re using Payload 3.0 (Next.js) with the Postgres adapter. Currently, we’re using push: true in local dev, but it’s causing friction:
The Issue: When Dev A pulls Dev B’s schema changes (like a column rename), the dev server triggers a "Data Loss Warning" because Drizzle tries to drop/add columns instead of renaming. This requires manual "yes/no" checks and DB babysitting.
The Question:
To reduce this mental overhead, do teams generally:

• Disable push: true locally and move to a strict migrate:create / migrate workflow for all local changes?
• Use a "Hybrid" approach (push while prototyping, then generate a migration once the feature is stable)?
• Use a custom script to automate migration creation/running on every dev server restart?

Any specific db adapter settings or package.json scripts you recommend to make the "pull and sync" experience seamless for teammates? Thanks!

[high vessel]

New Community-Help Thread Created!

Help is on the way! To mark it as solved, use the /solve command. In the meantime, here are some existing threads that may help you:

Documentation:

• Migrations - When to run migrations - Postgres
• The Payload Config - Compatibility flags
• Postgres - Prototyping in development mode

Community-Help:

• Implementing a Review Section: Valid Approach?
• Hide a field based on a role
• Recommended platforms to deploy a Payload app
• payload-types

[vapid hawk]

Still looking for help , thanks 🙏

[timid sigil]

I disable push by default on every development. It's starts breaking thing sooner or later.

[subtle thunder]

this has been a major pain point with payload. We never found a good solution

[tight jasper]

@vapid hawk our hybrid approach is different - we do use push because it's a lot more convenient than manually updating the DB, and since often features are scaffolded column-by-column. What I wouldn't recommend is disabling it entirely.

However, if it can't figure out a rename then I would do those changes manually. You can for example generate a migration and run it against your dev DB, but sometimes I also just quickly write it by hand, because we don't push unfinished migrations - e.g. we don't have 10 migrations per feature usually, especially not if each migration is just changing a column.

But in my experience Drizzle is quite capable of figuring out when columns need a rename, and only drops them if there's a type mismatch.

Hope that helps!

[vapid hawk]

Thanks for taking time to reply 🙏. Would you mind sharing a scenario where push broke something for you, pretty please, TIA 🙌 .

[vapid hawk]

I'll share my thoughts if I find any 👍