SQL Dialect Converter

Details

About this tool

Rewrites a query from one SQL dialect into another across sixteen of them. It parses the statement into a syntax tree and prints it back out in the target dialect, so the result is a rewrite rather than a search and replace.

The differences it handles are the ones that make a migration tedious. T-SQL's TOP becomes LIMIT or FETCH FIRST depending on the target. Oracle's NVL becomes COALESCE, MySQL's IFNULL likewise. Backticks become double quotes or square brackets. Date arithmetic is rebuilt entirely: DATE_ADD, DATEADD, INTERVAL and the plain plus-a-number that Oracle accepts are four different spellings of one idea, and none of them survive a copy and paste.

Getting this wrong quietly is the real risk, which is why the engine is a parser and not a set of regular expressions. A pattern that turns TOP 10 into LIMIT 10 will also mangle a column named TOP, and it has no idea that string concatenation is || in PostgreSQL, + in T-SQL and CONCAT in MySQL. A syntax tree knows what each token is, so it can leave alone what should not change.

Treat the output as a first draft. Structure, functions and quoting translate reliably; what no rewriter can bridge are vendor hints, procedural blocks, and the subtler differences in NULL ordering, collation and integer division. Read it before running it against anything that matters - and when a query will not parse, the service tries the other dialects and names the ones that do accept it, because the cause is almost always the source dialect rather than broken SQL.

This is the one tool here that sends your input to a server, and it says so on the page. The transpiler that gets this right is SQLGlot, which is Python: the WebAssembly build is a 21 MB download, larger than the rest of this site, and the JavaScript port still mistranslates ordinary queries. Nothing is stored - the query is parsed, printed and forgotten.

Good to know

Questions people actually ask

Why does this one send my query to a server?

Because the transpiler that gets it right is Python. The WebAssembly build is a 21 MB download - larger than the rest of this site - and the JavaScript port still mistranslates ordinary queries. Sending the text is the honest trade, so this tool is marked as one that uploads rather than one that runs on your device. Nothing is stored: the query is parsed, printed and forgotten.

Is the output ready to run?

Treat it as a first draft. Structure, functions and quoting are translated reliably, but dialects differ in ways no rewriter can bridge - vendor-specific hints, procedural blocks, and subtle differences in NULL ordering, collation and integer division. Read it before you run it against anything that matters.

It says my SQL cannot be parsed, but it looks fine.

Then the source dialect is almost certainly wrong. Backticks are a syntax error to PostgreSQL, TOP is meaningless to MySQL, and either produces a parse failure at the first offending character. The service tries the remaining dialects and names the ones that do accept your query, so the message usually tells you which to switch to.

Why not use find and replace?

Because a pattern cannot tell code from a name. A rule that turns TOP 10 into LIMIT 10 also breaks a column called TOP, and no pattern knows that string concatenation is || in PostgreSQL, + in T-SQL and CONCAT in MySQL. Parsing into a syntax tree means the tool knows what each token is, and leaves alone what should not change.

Can it convert a whole schema dump?

Up to a point: 200 statements or about 100 kB per run. Beyond that the tool would be tying up a shared server for a job better done with SQLGlot on your own machine - it is open source and the same engine.