Can Vercel rollbacks be coordinated with database schema migrations?

Vercel deployments use immutable builds where a rollback re-points the production alias to a previous deployment. However, database schema migrations—typically executed via ORMs like Prisma or Drizzle during the build or as a separate CI step—modify a shared external data store that persists independently of the deployment alias.

The Compatibility Gap

When a deployment introduces a destructive schema change (such as dropping a column) and is subsequently rolled back, the production alias returns to the previous code version. This older code may then attempt to access database structures that no longer exist, as the platform's rollback mechanism does not revert external database state.

To ensure high availability, it is unclear how to best implement a gating mechanism that aligns the code version with the schema version during an alias swap. Specifically, when using the Edge Runtime, there is uncertainty regarding whether function metadata caching could prolong the period where mismatched code and schema versions coexist during a rollback.

• What is the recommended strategy for ensuring database compatibility when performing a Vercel production rollback?
• Does Vercel provide a native way to trigger compensating migrations when an alias is reverted?