AI Prompt to Write a Zero-Downtime Database Migration Plan
This database migration plan prompt is for backend engineers and DevOps teams who need to change a production schema (adding a column, splitting a table, changing a data type) without taking the application offline. Rather than asking for raw migration SQL, it asks the model to produce a sequenced plan built around the standard safe pattern: add the new structure, backfill data, dual-write or read from both paths during a transition window, then cut over and clean up the old structure only once everything is verified.
The prompt deliberately asks for rollback steps at every stage, not just one rollback plan at the end, because the riskiest part of a live migration is usually a partial failure midway through, not a clean failure at the start. It also asks the model to flag any step that would lock a table or block writes for more than a moment, since that's the detail most likely to turn a "zero-downtime" migration into an outage if it's missed.
For migrations big enough that the full plan runs long, Cuelara's Token Optimizer can compress the prompt and its context before you send it to an API-based workflow, which keeps repeated runs (one per environment, for example) from costing more tokens than they need to.
Prompt template
Want it sharper? Optimize this prompt with Prompt Optimizer, check it with the Prompt Debugger or shorten it with the Token Optimizer.
Example input
When to use it
- You're changing a production database schema and the application cannot have downtime
- You're splitting, renaming, or changing the type of a column that's actively read and written by live traffic
- You need a plan reviewable by a second engineer before running anything against production
- You're migrating between two database engines or table structures and need a staged cutover, not a single cutover event
Best practices
- Describe your actual database engine, table size, and read/write patterns, since the safe approach for a 10,000-row table differs from a 500-million-row one
- Ask explicitly for which steps can run concurrently with normal traffic versus which require a maintenance window, however short
- Request a rollback step after every stage, not just a single rollback plan at the end, so a partial failure has a clear recovery path
- Have a second engineer review the plan's locking behavior before running it, since even a correct-looking migration can still take an unexpected table lock under real load
Common mistakes
- Asking only for the migration SQL and skipping the backfill, dual-write, and cutover stages that actually prevent downtime
- Running the full plan against production without first testing it against a realistic copy of the data, including its size
- Dropping the old column or table in the same deployment as the cutover instead of leaving a verification window in between
- Assuming a plan is zero-downtime just because it was labeled that way, without checking which individual steps take locks
FAQs
What does zero-downtime database migration mean?
It means changing a production database's schema without taking the application offline or blocking reads and writes for more than a brief moment, typically by staging the change across multiple deploys instead of one.
What is the expand-and-contract pattern in database migrations?
It's a staged approach where you first add new schema alongside the old (expand), run both in parallel while verifying the new path, then remove the old schema only after the new one is fully trusted (contract), avoiding a single risky cutover.
Can AI write migration SQL that's safe to run directly against production?
AI-generated migration plans and SQL should always be reviewed by an engineer familiar with the actual table size, traffic pattern, and database engine version before running against production, since locking behavior varies significantly between engines and versions.
Which Cuelara tool helps with long or repeated migration prompts?
Token Optimizer — compresses a verbose migration prompt and its schema context, which helps when you're running similar prompts across multiple environments or services and want to cut API token costs.