AI Hallucination Risk in Database Migration: How We Mitigate It

The Specific Shape of the Risk

“Hallucination” is a vague word for a precise problem. In database work it takes four recognisable forms, and each has a different mitigation — which is the useful thing to know, because a general worry produces no defence.

Four Forms

• Invented identifiers. A column, table or schema that doesn’t exist. The most common and the most easily caught — the catalog is right there.
• Invented API. A PostgreSQL function that was never in PostgreSQL, often an Oracle built-in with a plausible new name. Caught by parsing and by the catalog.
• Plausible-but-wrong semantics. Valid SQL, real objects, different meaning. The dangerous one: DATE mapped to DATE, a join that returns the right number of rows for the wrong reason.
• Fabricated certainty. Not wrong code — a wrong claim about the code. “This conversion is complete” when it isn’t; “validated” when nothing was checked.

The Mitigations, In Order of Strength

Don’t ask the model. The strongest mitigation is architectural: the constructs we know — type mapping, function swaps, DDL shape — are handled by deterministic rules. A model cannot hallucinate an answer it was never asked to produce, and this removes the entire category for the most common conversions.

Ground in the catalog. Identifiers are checked against the real schema, not against how plausible they look. This kills forms one and two outright.

Parse before offering. Generated SQL is checked mechanically for structure before a human ever sees it — the dollar-quote balance check we added to our own transpiler after shipping a bug of exactly this shape is the same idea applied to ourselves.

Make refusal available. A model with no way to say “I don’t cover that” will always produce something. A curated knowledge floor gives it an honest answer to fall back on, and unrecognised constructs become gap entries instead of guesses.

Verify claims separately from output. The assistant does not get to assert that a migration is validated. Validation is a tool that runs, produces a report, and the report is what gets shown. Form four is mitigated by never letting the narrator also be the referee.

The Hard One

Plausible-but-wrong semantics survives every check above, because the output is structurally perfect. Nothing detects it at generation time — only comparison with the source system does. Which is the real argument for column-level checksums and per-partition cryptographic proof: they catch the class of error that no amount of care during conversion can rule out.

Row counts do not catch it. Row counts match when a numeric was truncated, when a timestamp lost its time component, when an empty string became a NULL. That is the entire reason validation has to go deeper.

The Uncomfortable Part

No vendor can promise zero hallucination, ourselves included. What is promisable is structural: bound where the model is allowed to decide anything, ground it in real state, check its output mechanically, let it refuse, and verify the result independently of the thing that produced it. Anyone claiming their model simply doesn’t make things up is describing a marketing position, not an architecture.