SQL Dialect Translator

Translate SQL Between MySQL, PostgreSQL, SQL Server, Oracle and More

Paste a query written for one database and get it back rewritten for another. This SQL dialect translator handles the nine dialects teams actually move between — Standard SQL, MySQL, PostgreSQL, SQL Server (T-SQL), Oracle, SQLite, BigQuery, Redshift, and Snowflake — and it detects the source dialect for you, so in most cases the only thing you have to choose is where the query is going.

It is aimed at the specific, tedious part of a migration: the syntax that differs for no good reason. LIMIT versus TOP versus ROWNUM. Backticks versus double quotes versus square brackets. IFNULL versus ISNULL versus NVL versus COALESCE. None of that is hard, all of it is slow, and getting it wrong produces a syntax error at the worst possible moment. Everything runs client-side in your browser, so query text — which frequently contains table names, column names, and business logic you would rather not paste into someone else’s server — never leaves your machine.

What Gets Translated

• Row limiting — LIMIT n, LIMIT offset, count, SELECT TOP n, OFFSET … FETCH NEXT, and Oracle’s ROWNUM predicate, converted in every direction.
• Identifier quoting — MySQL and BigQuery backticks, SQL Server square brackets, and the ANSI double quotes used by PostgreSQL, Oracle, SQLite, Redshift, and Snowflake.
• Null-handling functions — IFNULL, ISNULL, NVL, and COALESCE, plus the date, string, and conversion functions that carry different names in each dialect.
• Cast syntax — PostgreSQL’s :: shorthand expanded into CAST(… AS …) and back where the target supports it.
• Type names — SERIAL, AUTO_INCREMENT, IDENTITY, TEXT, NVARCHAR, JSONB, NUMBER, and the rest mapped to the closest equivalent.
• String concatenation — the ANSI || operator, MySQL’s CONCAT(), and T-SQL’s +.
• Boolean literals — TRUE/FALSE where supported, 1/0 for SQL Server, Oracle, and SQLite, which have no native boolean type.

Every substitution the translator makes is recorded as a warning with the original text, the converted text, and the line number, so the output is auditable rather than a black box. Warnings are also where the translator tells you what it could not do faithfully — a type with no exact equivalent, or a construct that changes semantics in the target.

How to Use It

1. Paste your SQL into the left panel. Detection runs after a short pause in typing, and the detected dialect appears with a confidence indicator.
2. Confirm or override the source. Auto-detect is on by default. Turn it off and pick the source dialect yourself when the query is too short or too generic to fingerprint.
3. Choose a target dialect. The translated SQL appears in the right panel immediately, syntax-highlighted.
4. Read the warnings panel. Anything the translator changed or could not change confidently is listed there with a line reference.
5. Load an example to see the behaviour. Six worked pairs are built in, including PostgreSQL to MySQL, T-SQL to PostgreSQL, Oracle to PostgreSQL, and PostgreSQL to BigQuery or Snowflake.

The editor panes are resizable, which matters when you are working with a query long enough to need a migration tool in the first place.

Worked Example: T-SQL to PostgreSQL

Given this SQL Server query:

SELECT TOP 10 id, [user name], GETDATE() AS now FROM [user table] WHERE ISNULL(deleted, 0) = 0 AND active = 1

Four separate rules fire. SELECT TOP 10 becomes a trailing LIMIT 10. The square-bracketed identifiers [user name] and [user table] become double-quoted. GETDATE() becomes CURRENT_TIMESTAMP. ISNULL(deleted, 0) becomes COALESCE(deleted, 0). The active = 1 comparison is flagged rather than silently changed, because in PostgreSQL active may be a genuine boolean column, in which case the correct rewrite is active = TRUE — and the translator cannot know your schema.

Row Limiting Across Dialects

Note the trap in the SQL Server and Oracle offset forms: both require an ORDER BY clause. A LIMIT without ordering is legal in MySQL and PostgreSQL but returns an arbitrary ten rows; translated into T-SQL it becomes a syntax error. That is a case where the target dialect is doing you a favour.

What a Syntax Translator Cannot Do

Treat the output as a strong first draft, not a finished migration. Syntax translation is mechanical; semantics are not. Specifically:

• Type precision differs. MySQL DATETIME and PostgreSQL TIMESTAMP look equivalent but differ in range, precision, and time-zone handling. Oracle NUMBER maps to several PostgreSQL types depending on scale.
• Empty string versus NULL. Oracle treats '' as NULL; nothing else does. Queries that rely on that behaviour change meaning after translation, and no rewrite of the SQL text can fix it.
• Case sensitivity. Unquoted identifiers fold to lowercase in PostgreSQL and to uppercase in Oracle. Quoting them — which the translator does when the source quoted them — makes the case significant, which can turn a working query into “column does not exist”.
• Stored procedures, triggers, and window-function extensions are out of scope. The translator works on query syntax, not procedural language.
• Collation and sort order vary by database and locale, so ORDER BY results may not match row for row.

Always run the translated query against a copy of the target database and compare results before trusting it. If you also need the output readable, run it through the SQL formatter afterwards.

Frequently Asked Questions

How does the dialect detection work?

It scores the query against fingerprints for each dialect — backtick or bracket quoting, TOP versus LIMIT, dialect-specific function names like NVL or GETDATE, the :: cast operator — and reports the best match with a confidence value. Short or fully ANSI-standard queries have nothing distinctive to detect, so set the source dialect manually in those cases.

Is my SQL uploaded anywhere?

No. Detection, translation, and highlighting all run in JavaScript in your browser. Nothing is transmitted, stored, or logged.

Can it convert a whole schema or a migration file?

It works on query syntax, and it will process multiple statements, but it is not a schema migration tool. DDL is translated on a best-effort basis for common type names; constraints, indexes, partitioning, and stored procedures need manual review.

Why does it warn instead of just converting?

Because some rewrites depend on your schema. active = 1 in T-SQL may be a boolean or a genuine integer flag; converting it blindly would break one of those cases. The warnings panel exists so those judgement calls stay with you.

Which direction is best supported?

Translations into PostgreSQL and MySQL are the most heavily exercised, since those are the most common migration targets. All nine dialects are supported in both directions, but the further a construct is from ANSI SQL, the more likely you are to see a warning rather than a clean rewrite.

Does it handle Snowflake, BigQuery, and Redshift?

Yes, all three are first-class dialects. Their divergences are mostly in type names, quoting, and the cast operator, which are exactly the categories the translator covers — but their analytics-specific extensions (BigQuery STRUCT and ARRAY, Snowflake VARIANT) have no equivalent elsewhere and are flagged rather than converted.

What about SQL injection risk in pasted queries?

The tool never executes anything — it does text transformation only. That said, translating a query does not make it safe: if the original concatenated user input into the SQL string, the translated version does too. Parameterise queries in your application code regardless of dialect.

Is it free?

Yes — unlimited use, no account, no rate limit. It sits alongside the SQL formatter and cron expression builder in our developer toolkit.