Netlify Deploys ↔ Database Migrations: Unresolved Zero‑Downtime Strategy

Goal

Plan a zero‑downtime migration for a small application moving to Netlify, ensuring that static assets, preview environments, and database schema changes coexist without service interruption.

Key Constraints & Uncertainties

• Atomic deploys swap in a fully built build only after successful completion, but they do not manage stateful database changes.
• Split traffic routing can gradually expose new code to users, yet its interaction with database migrations remains unclear.
• Netlify Functions are stateless; each invocation must establish a fresh database connection, leading to cold‑start latency.
• Functions are subject to a 10‑second (free) or 15‑second (paid) execution timeout, limiting the complexity of migration scripts that can run inside them.
• Netlify’s CI/CD pipeline does not automate schema migrations; external tools are required.

Unresolved Questions

1. Can a database migration be safely triggered during an atomic deploy without exceeding function timeouts, or must migrations be handled entirely outside Netlify’s deployment process?
2. Is it feasible to use split traffic to gradually roll out new database schemas—e.g., routing a small percentage of traffic to a version that applies the migration first—while keeping the rest of the traffic on the old schema?
3. What best‑practice pattern exists for minimizing cold‑start latency in Netlify Functions that perform database operations during a migration window?