Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For a production schema change, keep the old and new database representations compatible with every application version that may be running during rollout. The reliable pattern is to expand the schema, backfill and validate data, switch application behavior, and contract the schema only after old code is gone. Prisma demonstrates this as separate production deploys for expansion and contract, but the total number of releases depends on your rollout and data-migration needs.
Why a schema change must span deploys
During a rolling deployment, old and new application instances can run at the same time. If a migration immediately renames or drops a field that the old version still uses, that version can fail even if the new code works. A safe change keeps the database usable by both versions during the overlap, then removes the old representation only when no active code depends on it.
This staged method is commonly called expand and contract. Prisma describes it as two reviewable steps: add the new column and copy data across, then remove the old column once nothing reads it. The underlying principle is compatibility across the rollout, not a promise that every system needs exactly two deploys. Prisma’s expand-and-contract guide
The rollout sequence
1. Expand the schema
Add the replacement column, table, or representation without removing the old one. Confirm that the currently deployed application continues to work with this expanded schema. The expansion must be safe for old code as well as ready for the eventual new code.
#1 Best Overall
2. Backfill and validate existing data
Move existing values into the new representation with an intentional mapping, then validate that the result preserves their meaning. A default value is not necessarily a correct transformation for existing rows. In Prisma’s example, assigning a default status of Draft would incorrectly classify posts that had already been published. The guide instead retains the existing published boolean, adds a status enum column, maps published rows appropriately, and verifies representative results before switching application behavior. See Prisma’s column-replacement walkthrough
3. Switch application reads and writes
Deploy application code that reads and writes the new representation while the old one remains available. Let the rollout finish, and establish that no active version still reads or writes the old field. That check matters because a deployment can leave old instances, workers, or other application processes active longer than expected.
4. Contract the schema
Remove the old field only after old application code is retired and no active process accesses it. Treat this destructive cleanup as a separate change: plan and review the migration rather than bundling it into the code switch. Prisma’s guide marks dropping the old column as destructive and shows the contract applied in a later production deploy.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 115. Observe and preserve a recovery path
Inspect database state and review the planned operations before applying a migration. Decide how to recover if the rollout fails: after a field is dropped, a simple application rollback may no longer be possible unless you have a reverse migration or preserved the removed data. The exact recovery plan depends on the database and deployment system; there is no universal rollback guarantee.
How the Prisma ORM example handles migrations
Prisma’s current documentation identifies Prisma ORM 8 as the current release and maintains a separate guide for supported Prisma ORM 7 installations. Follow the documentation for your installed version: commands and workflows are version-specific. In the ORM 8 workflow, the documented sequence is to emit the contract, plan a migration, review the planned operations and SQL, and then apply the migration. Prisma’s migration system records a contract-state marker and links states in a migration graph; db migrate uses that marker to determine what is pending. How migrations work · The migration graph · Applying a migration
In the documented column-replacement example, the expansion keeps published, adds status, backfills and verifies the new values, and then changes application reads and writes to use status. Only after nothing reads or writes published does the contract remove that old column. Prisma recommends reviewed migrations for production rather than directly reconciling the contract with db update. The example illustrates separate expansion and contract production deploys with the application switching between them; other deployments may require additional releases or migration work.
Database support is also version-sensitive. Prisma’s current ORM 8 documentation lists PostgreSQL and MongoDB as supported, SQLite as experimental, and MySQL as unsupported. Check the current vendor documentation for your version and database before relying on that status, which may change.
What this pattern does—and does not—guarantee
Expand and contract addresses application compatibility while versions overlap; it does not establish that a migration is free of locks, table rewrites, runtime cost, or other database-specific impact. Those depend on the engine, operation, data, and deployment conditions. The sources describe the staged sequence, not universal performance or lock guarantees. For a one-shot change versus a staged change, assess compatibility with old and new code, the data mapping and validation involved, database impact, how long both representations must coexist, and how each approach can be recovered if rollout fails.
Plan the change around compatibility, not a deploy count
Use separate, reviewable stages so the database remains compatible while code and data move to the new representation. The two-deploy example is a useful model, not a universal quota: the important gates are that the new representation exists and is validated before code switches, and that old code is gone before the old representation is removed.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
