Inspiration
Schema migrations are the scariest "small" change in software. A migration that runs without errors can still silently drop rows, turn NULLs into garbage, or leave a rollback script that doesn't actually restore anything. Teams usually find out in production. Personally I saw my friends doing naive inner join and lose data on their initial days of their internship, thankfully the senior devs managed it.
We wanted a way to prove a migration is safe before it ever touches a real database, and to let an AI agent do the tedious work of writing and fixing it.
What it does
SQL Migration Time Machine is an autonomous agent that drafts a schema migration, runs it on a disposable in-memory clone of your database, and only accepts it once it passes formal checks.
- Connect a built-in scenario, an uploaded SQLite file or a local database.
- Plan: the model writes a machine-checkable spec (column mappings, null policies, row policy) that you review and approve.
- Run: the agent drafts the migration with Nemotron, verifies it on a sandbox clone, and repairs it using structured failure telemetry, escalating from Nemotron 3 Super to Ultra.
- Result: you get a verified UP script, a DOWN script, and a report. The rollback is classified (exact, equivalent after normalization, lossy or broken).
- History keeps every run.
How we built it
- Spec-first verification. The approved spec defines an oracle: for every source row, the verifier computes the expected output and compares it with what the migration produced. no row may be lost, changed or corrupted. On top of that we check invariants: row preservation, constraints, indexes, triggers and foreign keys.
- Adversarial trap rows are injected into every clone: NULLs, single-word names, emoji, tab-padded whitespace, currency strings, orphan foreign keys, SQL punctuation and very long strings.
- Hardened sandbox. Migrations run in-memory under a SQLite authorizer and a time limit, so generated SQL can't touch disk.
- A tool-using agent loop on Nebius Token Factory with NVIDIA Nemotron models: schema and profile tools, a "try it on a clone" tool, and a submit tool, with repair memory across attempts.
- Streamlit UI, a CLI, and a test suite of 100+ tests, including a corpus of deliberately broken migrations that the verifier must catch.
Challenges we ran into
- Parsing model output. Our first parser sometimes concatenated the rollback script onto the UP script, so a correct migration undid itself. We fixed it with stricter markers and a self-undo guard.
- Unsatisfiable plans. The model could ask for a column to be NOT NULL when the data contained NULLs. We added spec validation against the real schema and profile.
- SQLite details.
TRIM()only strips spaces, while our oracle strips tabs too. A rollback can't be byte-exact when the migration must trim data, so we classify rollbacks instead of demanding bit-for-bit equality. - Agents that oscillate. Early repair prompts only showed the latest failure, so the model fixed one problem and reintroduced another. We added attempt history and accumulated requirements.
- Timeouts and cost. Large models are slow, so we budget time per attempt and cap tool rounds.
Accomplishments that we're proud of
- A verifier we calibrated against hand-written correct migrations and a corpus of broken ones, so it neither rubber-stamps nor blocks good work.
- A sandbox that treats AI-generated SQL as untrusted code.
- Honest failure reporting: every attempt shows its model, failed checks and sandbox errors instead of a vague "failed".
What we learned
Letting an LLM write the migration is the easy part. The hard part is deciding what "correct" means in a form a machine can check, and keeping the agent from chasing its own tail. Good verification, specific error messages and memory across attempts mattered more than a bigger model.
What's next for SQL Migration Time Machine
- First-class Postgres and MySQL adapters with the same spec-and-oracle approach.
- Verification that scales to very large tables by sampling plus aggregate checksums.
- Faster, cheaper runs by using the small model for syntax errors and escalating only when needed.
- Exporting verified migrations directly into Alembic, Flyway and similar tools.
Log in or sign up for Devpost to join the conversation.