Any wayt to avoid all downtime with prisma?
Back whenever, with hibernate when we dropped columns, we would 1. deploy app that no longer reads/writes columns and 2. run migration while live app is running to drop columns.
Voila - no downtime for customers.
In prisma, does this work? I suspect we keep adding breaking changes and doing this wrong but then I add a few columns locally and one of my other servers locally hitting same DB BREAKS!!!
This second scenarios is
1. run migration - old servers should work but seem not to
2. deploy app that uses new columns
hibernate worked great in this case but in this second case, I add columns (nullable at first) and it seems to break things. I may need to pay closer attention but putting this out there in case others see this behavior before I go down a rabbit hole investigation(ie. some prelim knowledge of what way it works would be nice).
1 Reply
Skipping coffee for instant knowledge! Let's brew that AI answer now.
Prisma can support zero-downtime schema changes if you follow the right patterns, similar to what you described with Hibernate. The recommended approach is the "expand and contract" pattern:
1. Add new columns as nullable: Deploy the migration while your old app is still running. This is safe—existing servers should not break, as Prisma Client queries select only the columns defined in the schema at generation time, not all columns in the DB. Adding nullable columns is non-breaking and should not affect running servers or clients, as long as you don't remove or change existing columns/types in a breaking way [Expand and Contract Pattern].
2. Update your app to use the new columns: After the migration, deploy your updated app that reads/writes the new columns.
3. Remove old columns: Once all app instances are updated and no longer use the old columns, you can safely drop them in a separate migration.
If you see old servers breaking after adding columns, that's unexpected—adding nullable columns should not break existing Prisma Clients, as they only select fields defined in their generated schema [Why does prisma select each individual column instead of a * when no select clause is included?]. Problems usually arise when you remove or rename columns before all servers are updated.
For destructive changes (like dropping columns), always ensure your app is no longer referencing them before running the migration. This staged approach avoids downtime and errors, just like with Hibernate.
If you’re seeing breakage after simply adding columns, double-check that you’re not making other schema changes at the same time, and that your Prisma Client is up to date with your schema. If issues persist, more investigation may be needed, but the do
cumented pattern should work for zero-downtime deployments [Implementation Guidance for Expand and Contract Pattern].
✅ Great, thanks for letting us know that this solved your question!