SchemaGate doubled its Oracle score by teaching the prompt the dialect—not by changing the model

SchemaGate 1.10 makes a focused argument about text-to-SQL quality: before replacing the model, tell it the database’s actual dialect rules.

The project says its new Oracle-specific prompt raised first-try accuracy on the Oracle dialect of UniQL from 35.0% to 64.5%. The test covered 1,534 questions and used Gemini 2.5 Flash, according to the release notes. SchemaGate also says the best previously published result on that slice is 49.6%. These are project-reported comparisons, not an independent replication. SchemaGate 1.10 release

What changed

For Oracle targets, SchemaGate now tells its SQL generator several rules explicitly: omit AS before table aliases, quote reserved-word column names, use FETCH FIRST instead of LIMIT, and prefer Oracle forms such as NVL, the || concatenation operator and Oracle date functions. The change flows through the project’s generate_sql path and therefore also affects its answer flow, command-line interface and Studio. Prompts for other dialects are unchanged. SchemaGate 1.10 release

That narrow scope matters. The release does not claim a broadly smarter semantic parser; it claims that removing predictable dialect errors can recover a large amount of accuracy on one benchmark slice. For teams operating across PostgreSQL, MySQL and Oracle, this is a reminder that a shared semantic layer does not erase SQL-generation differences at the final mile.

What to verify before adopting the number

SchemaGate says the release includes benchmark outputs for BIRD Mini-Dev across SQLite, PostgreSQL and MySQL, UniQL Oracle, plus end-to-end OAuth tests against Keycloak in CI. But the headline Oracle result should still be treated as a reported result until another party reproduces it under the same evaluator, model version and decoding settings. SchemaGate 1.10 release

A practical rollout test is straightforward: replay an internal Oracle query set before and after the prompt change, classify failures by syntax versus schema or business-logic error, and inspect whether the new rules improve valid execution without merely fitting benchmark conventions. If syntax failures fall while semantic failures remain flat, the release has done exactly what it claims—and also shown where the next work lies.