Routing Database Migrations to Claude: When to Use Opus vs. Sonnet

Quick answer

Opus vs Sonnet migrations comes down to risk and complexity: use Opus for schema changes that touch multiple tables, foreign keys, or production data transformations where correctness matters more than cost; use Sonnet for routine column additions, index creation, or low-risk changes where speed and budget matter. Most teams route by detecting migration risk signals—table count, constraint changes, data backfills—and let the simpler model handle the majority while escalating the dangerous 10-20% to Opus.

Key takeaways

Opus excels at multi-table schema changes, constraint logic, and data transformations where a mistake costs hours of rollback or data loss
Sonnet handles routine migrations faster and cheaper: adding columns, creating indexes, renaming fields in isolated tables
Risk detection drives routing: count affected tables, check for foreign keys or triggers, flag backfills or production data moves
Auto-approval gates by migration type let safe Sonnet migrations run unattended while Opus changes wait for human review
Escalation workflows start with Sonnet, detect failure or complexity signals, and re-route to Opus without losing context
Parallel migration lanes run low-risk changes in separate worktrees or folders, each with the right model, monitored from your phone

Why Database Migrations Demand Different Model Capabilities

Database migrations sit at the intersection of schema design, data integrity, and production risk. A single mistake—dropping the wrong column, missing a foreign key cascade, or writing a backfill that locks a table for minutes—can break deployments or corrupt data. Unlike feature code where tests catch most errors, migrations often run once in production with no second chance.

Opus vs Sonnet migrations matters because the two models have different strengths. Opus (Claude 3 Opus, the larger model) reasons through complex multi-step logic: it tracks foreign key dependencies across tables, understands transaction boundaries, and writes safer data transformations. Sonnet (Claude 3.5 Sonnet, the faster model) excels at straightforward schema changes where the path is clear: adding a nullable column, creating an index, or renaming a field. Sonnet costs less and responds faster, but it can miss edge cases in complex scenarios.

The practical question isn’t “which model is better” but “which migration needs which model.” A migration that adds a single last_login_at timestamp to a users table is a Sonnet task. A migration that splits a monolithic orders table into orders, line_items, and payments with foreign keys, triggers, and a data backfill is an Opus task. Most teams see a distribution: 70-80% of migrations are routine and safe for Sonnet; 10-20% are complex enough to justify Opus; and a small tail of truly dangerous changes need Opus plus human review.

The cost difference is real but not prohibitive. Opus costs roughly 15x more per token than Sonnet (as of early 2025 pricing). A typical migration conversation might consume 5,000-10,000 tokens (prompt + response). Routing to Sonnet costs pennies; routing to Opus costs a few dollars. For a routine migration, Sonnet’s speed and cost win. For a complex migration, Opus’s correctness is worth the extra dollars—especially when the alternative is a production incident that costs hours of engineering time.

Opus for Complex Schema Changes: Cost vs. Correctness Trade-off

Opus for migrations makes sense when the schema change involves multiple tables, foreign key constraints, triggers, or data transformations where correctness is non-negotiable. Opus handles these scenarios better because it maintains a richer mental model of the database structure and reasons through multi-step logic more reliably.

Scenarios where Opus is the right choice:

Multi-table schema changes: splitting or merging tables, adding foreign keys that span tables, or refactoring a normalized structure
Data backfills with business logic: copying or transforming production data where a bug could corrupt records (e.g., migrating user preferences from JSON to relational tables)
Constraint changes: adding or modifying foreign keys, unique constraints, or check constraints where the model must understand existing data patterns
Trigger or stored procedure logic: writing or modifying database-side logic that interacts with application code
Rollback-critical migrations: changes where a mistake requires a complex rollback or data recovery

The cost vs. correctness trade-off is straightforward: Opus might cost $2-5 for a complex migration conversation, but a production bug from a bad migration can cost hours of engineering time, customer impact, and rollback complexity. Teams that route complex migrations to Opus report fewer rollbacks and faster reviews because the generated SQL is more likely to be correct on the first pass.

Example workflow: you’re splitting a users table into users and user_profiles with a one-to-one foreign key. The migration must create the new table, copy data, add the foreign key, update application queries, and handle null cases. Opus tracks the dependency order, writes the data copy with proper transaction boundaries, and suggests an index on the foreign key. Sonnet might generate a working migration but miss the index or write a data copy that locks the table longer than necessary.

Sonnet for Routine Migrations: Speed and Budget Alignment

Sonnet handles the majority of migrations: adding columns, creating indexes, renaming fields, or dropping unused tables. These changes are low-risk, well-understood, and don’t require deep reasoning about multi-table dependencies. Sonnet’s speed and cost make it the default choice for routine schema evolution.

Scenarios where Sonnet is the right choice:

Adding nullable columns: new fields that don’t require backfills or constraints
Creating or dropping indexes: performance tuning that doesn’t change data or application logic
Renaming columns or tables: straightforward refactors with clear before/after states
Dropping unused columns or tables: cleanup tasks where the risk is low (assuming you’ve verified nothing uses them)
Simple constraint additions: adding a NOT NULL constraint to a column that’s already populated, or a default value

Sonnet responds faster (often 2-3x quicker than Opus for the same prompt) and costs significantly less. For a team running dozens of migrations per sprint, routing routine changes to Sonnet keeps costs predictable and turnaround fast. The model is reliable for these tasks because the logic is straightforward and the failure modes are obvious (syntax errors, missing semicolons) rather than subtle (wrong transaction isolation level, missed edge case).

Example workflow: you need to add a stripe_customer_id column to the users table. The column is nullable, no backfill required, and the application will populate it lazily. You send the task to Sonnet: “Add a nullable stripe_customer_id varchar(255) column to the users table.” Sonnet generates the migration in seconds, you review it on your phone, approve it, and the agent runs it in a staging environment. Total cost: a few cents. Total time: under a minute.

Real Workflow: Detecting Migration Risk and Routing to the Right Model

The practical challenge is detecting migration risk before you route to a model. Most teams don’t manually decide “this is an Opus migration” for every change—they use heuristics or tooling to classify migrations and route automatically.

Risk signals that suggest routing to Opus:

Table count: the migration touches more than one table
Foreign key changes: adding, modifying, or dropping foreign keys
Data backfills: the migration includes UPDATE or INSERT statements that transform production data
Constraint logic: adding CHECK constraints, unique indexes, or triggers
Production flags: the migration targets a production database or a table with millions of rows
Rollback complexity: the migration doesn’t have an obvious inverse (e.g., dropping a column with data)

Risk signals that suggest Sonnet is safe:

Single table, single column: adding or dropping one field in one table
Index-only changes: creating or dropping indexes without touching data
Rename-only changes: renaming a column or table with no logic changes
Staging-first: the migration runs in a staging environment where mistakes are cheap

Practical routing workflow:

Parse the migration prompt or file: extract table names, SQL keywords (ALTER TABLE, CREATE INDEX, UPDATE, FOREIGN KEY)
Count risk signals: how many tables? Any foreign keys? Any data transformations?
Route based on score: 0-1 signals → Sonnet; 2+ signals → Opus
Override for production: if the target is production, escalate to Opus or require human review regardless of risk score

Some teams build this logic into a CLI wrapper or a pre-commit hook. Others rely on the agent to self-assess: “Is this migration complex enough to need Opus?” and trust the model to escalate. MobileVibe users often set up conversation routing rules in their project config: migrations in the db/migrations folder with certain keywords trigger Opus; everything else defaults to Sonnet.

Setting Up Auto-Approval Gates by Migration Type

Auto-approval gates let safe migrations run unattended while risky ones wait for human review. This is critical for opus vs sonnet migrations because you want Sonnet’s speed for routine changes but don’t want to approve every single one manually.

Auto-approval rules by migration type:

Sonnet + single table + no data changes: auto-approve (e.g., adding a nullable column, creating an index)
Sonnet + multiple tables or data changes: require approval
Opus + any migration: require approval (Opus is expensive enough that you want to review the output)
Production target: always require approval, regardless of model or risk

Implementation in MobileVibe workflows:

MobileVibe’s Desktop Connector supports auto-approve controls where the agent can proceed without waiting for a phone tap. You configure these rules per conversation or per folder. For example:

Folder: ~/projects/api/db/migrations
Agent: Claude CLI with Sonnet
Auto-approve rule: ALTER TABLE with one table name, no UPDATE or DELETE, staging environment
Notification: send a push notification after the migration runs, with a link to the diff

For Opus migrations, you disable auto-approve and set up a notification: “Migration ready for review.” You open the conversation on your phone, read the generated SQL, and approve or reject. The agent waits in a paused state until you respond.

Example: you’re on a train, and your agent generates three migrations: (1) add email_verified_at to users (Sonnet, auto-approved), (2) create an index on orders.user_id (Sonnet, auto-approved), (3) split orders into orders and line_items (Opus, needs approval). You get one push notification for the Opus migration. You review it, approve it, and the agent proceeds. The two Sonnet migrations ran while you were reading the Opus one.

Monitoring Agent Decisions: When Sonnet Fails and Escalates to Opus

Escalation workflows handle the case where Sonnet starts a migration, hits a complexity signal, and needs to re-route to Opus. This is common in exploratory tasks where the agent doesn’t know the full scope until it inspects the schema.

Escalation triggers:

Sonnet generates SQL with errors: syntax errors, missing foreign keys, or constraint violations in a dry-run
Sonnet detects complexity mid-task: “I need to touch three tables to make this change work”
Human feedback: you review Sonnet’s output and say “this needs Opus”
Quota or rate-limit hit: Sonnet exhausts its token budget and the task isn’t done

Practical escalation flow:

Start with Sonnet: the agent begins the migration task with the faster, cheaper model
Detect failure or complexity: Sonnet generates SQL, runs a dry-run in staging, and sees constraint violations or realizes it needs to touch multiple tables
Escalate to Opus: the agent switches models mid-conversation, re-prompts with the full context (“I tried this with Sonnet, here’s what failed”), and asks Opus to solve it
Notify the developer: send a push notification: “Migration escalated to Opus for review”
Human approval: you review Opus’s output and approve or iterate

MobileVibe makes this workflow practical because the conversation stays live on your desktop while you monitor from your phone. The agent doesn’t lose context when it switches models—it’s the same conversation, same folder, same terminal session. You see the escalation in real-time and can approve the Opus output without re-explaining the task.

Example: you ask Sonnet to “add a foreign key from orders.user_id to users.id.” Sonnet generates the SQL, runs a dry-run, and discovers that 500 rows in orders have user_id values that don’t exist in users. Sonnet escalates: “This migration needs a data cleanup step. Switching to Opus.” Opus analyzes the orphaned rows, suggests a backfill strategy (delete them, or create placeholder users), and writes a two-step migration. You approve it from your phone.

Multi-Agent Lanes: Running Safe Migrations in Parallel

Parallel migration lanes let you run multiple migrations at once, each in its own folder or worktree, each with the right model. This is useful when you have a batch of schema changes: some are routine (Sonnet), some are complex (Opus), and you want them all to progress without blocking each other.

Typical setup:

Lane 1: ~/projects/api/migrations/add-indexes (Sonnet, auto-approve, three index creations)
Lane 2: ~/projects/api/migrations/split-orders (Opus, needs approval, multi-table refactor)
Lane 3: ~/projects/api/migrations/cleanup-unused-columns (Sonnet, auto-approve, drop five columns)

Each lane is a separate conversation in MobileVibe, tied to a folder and an agent. You monitor all three from your phone’s dashboard. Lane 1 and Lane 3 run unattended (auto-approved Sonnet tasks). Lane 2 waits for your approval. You review Lane 2’s Opus output, approve it, and all three migrations complete in parallel.

Why this matters for opus vs sonnet migrations: you don’t want a complex Opus migration to block routine Sonnet migrations. By running them in separate lanes, you get the speed of Sonnet for the easy stuff and the correctness of Opus for the hard stuff, without serializing everything.

Practical workflow:

Identify migration batch: you have five migrations to run this sprint
Classify by risk: three are Sonnet-safe, two need Opus
Create lanes: set up three conversations (or worktrees) for the Sonnet migrations, two for the Opus migrations
Start all lanes: kick off all five agents from your desktop or via email
Monitor from phone: MobileVibe’s dashboard shows which lanes need approval, which are running, which are done
Approve Opus lanes: review and approve the two Opus migrations when they’re ready
Merge results: once all lanes finish, merge the migration files into your main branch

This workflow is common for teams that batch migrations at the end of a sprint or before a release. You want to ship all the schema changes at once, but you don’t want to manually route each one or wait for them to run sequentially.

FAQ

Should I always use Opus for database migrations?

No. Most migrations are routine schema changes (adding columns, creating indexes) where Sonnet is faster, cheaper, and reliable. Reserve Opus for complex migrations: multi-table changes, foreign key logic, data backfills, or anything where a mistake is expensive. A good rule: if the migration touches one table and doesn’t transform data, start with Sonnet. If it touches multiple tables or includes business logic, use Opus.

How do I know if a migration is complex enough to route to Opus?

Count risk signals: Does it touch more than one table? Does it add or modify foreign keys? Does it include UPDATE or INSERT statements that transform production data? Does it add constraints or triggers? If you see two or more signals, route to Opus. If it’s a single-table, single-column change with no data transformation, Sonnet is safe. You can also let the agent self-assess: start with Sonnet and escalate to Opus if it detects complexity mid-task.

Can I start with Sonnet and escalate to Opus if the migration fails?

Yes, and this is a common workflow. Start the migration with Sonnet. If Sonnet generates SQL with errors, detects multi-table dependencies, or realizes the task is more complex than expected, escalate to Opus mid-conversation. The agent re-prompts Opus with the full context (what Sonnet tried, what failed) and continues from there. MobileVibe keeps the conversation live on your desktop, so the escalation is seamless—you just see a notification that the model switched and the task needs approval.

What’s the actual cost difference between routing to Opus vs. Sonnet for a typical migration?

Sonnet costs roughly $0.003 per 1,000 input tokens and $0.015 per 1,000 output tokens (as of early 2025). Opus costs roughly $0.015 per 1,000 input tokens and $0.075 per 1,000 output tokens—about 5x more for input, 5x more for output. A typical migration conversation uses 5,000-10,000 tokens total. Sonnet: $0.05-0.15. Opus: $0.25-0.75. The difference is a few dollars per migration. For routine changes, Sonnet’s speed and cost win. For complex changes, Opus’s correctness is worth the extra cost.

How does MobileVibe help me monitor and approve migrations from my phone?

MobileVibe’s dashboard shows all active conversations (agent sessions) on your desktop. When a migration needs approval, you get a push or email notification. You open the conversation on your phone, read the generated SQL, see the diff, and tap “Approve” or “Reject.” The agent proceeds or stops based on your input. For auto-approved migrations, you get a notification after they run with a link to the result. You’re not SSH-ing into a server or opening a laptop—you’re just tapping a notification and reading a diff.

Can I run multiple migrations in parallel with different models?

Yes. Set up separate conversations (or worktrees/folders) for each migration, each with its own agent and model. Sonnet migrations run in one lane, Opus migrations in another. MobileVibe’s dashboard shows all lanes at once. You monitor them from your phone, approve the Opus lanes when ready, and let the Sonnet lanes run unattended. This is common for teams that batch migrations: run the safe ones in parallel with Sonnet, run the complex ones in parallel with Opus, and merge the results when all lanes finish.

Routing opus vs sonnet migrations is about matching model capabilities to migration risk. Most teams route by detecting complexity signals—table count, foreign keys, data transformations—and let Sonnet handle the majority while escalating the dangerous 10-20% to Opus. MobileVibe makes this workflow practical by letting you monitor agent decisions, approve migrations, and run parallel lanes from your phone. If you’re tired of manually deciding which model to use or missing migration approvals because you’re away from your desk, try MobileVibe free and route your next batch of migrations from anywhere.

Routing Database Migrations to Claude: When to Use Opus vs.