Convert SQL between databases
Every pair with a dedicated guide, grouped by the database you are moving off. Each guide shows a real worked example of what changes — identifier quoting, row limiting, null handling — and opens the translator preloaded with that pair.
From MySQL
5 targets · versions 8.4, 8.0, 5.7
From PostgreSQL
5 targets · versions 17, 16, 15, 14, 13
From SQL Server
2 targets · versions 2022, 2019, 2017
From Google BigQuery
1 target · versions standard
From IBM DB2
1 target · versions 11.5, 11.1
From SQLite
1 target · versions 3.46, 3.45, 3.40
Need a pair that isn’t listed?
These fifteen have their own guides because they are the ones people search for, but the translator itself handles every combination of the 18 supported dialects. Pick any two in the editor and it works the same way.
Open the translatorWhat actually changes between SQL dialects
Eight things account for most of the work in any conversion. The translator handles all of them; knowing what they are makes the output easier to check.
- Row limiting
- MySQL and PostgreSQL take LIMIT 10. SQL Server wants SELECT TOP 10, placed before the column list rather than after the query. Oracle before 12c needed a ROWNUM filter in a subquery, and 12c onwards accepts FETCH FIRST 10 ROWS ONLY. The clause moves position, not just spelling.
- Quoting identifiers
- MySQL wraps identifiers in `backticks`. PostgreSQL, Oracle and Snowflake use "double quotes", which are also case-sensitive there. SQL Server uses [square brackets]. A query that merely mentions a reserved word as a column name will not run unchanged anywhere else.
- Auto-incrementing keys
- MySQL declares AUTO_INCREMENT, PostgreSQL uses SERIAL or a GENERATED ALWAYS AS IDENTITY column, SQL Server uses IDENTITY(1,1), and Oracle uses a sequence plus a trigger or an identity column. This is the single most common thing that breaks a schema migration.
- String concatenation
- The SQL standard operator is ||, which PostgreSQL, Oracle and SQLite accept. SQL Server uses + and MySQL needs CONCAT() — in MySQL, || means logical OR unless PIPES_AS_CONCAT is set, so the same expression silently returns a boolean instead of failing.
- Date and time functions
- NOW() in MySQL and PostgreSQL, GETDATE() in SQL Server, SYSDATE in Oracle, CURRENT_TIMESTAMP everywhere as the portable spelling. Date arithmetic diverges further: DATE_ADD, DATEADD, INTERVAL literals and plain addition are four different answers to the same question.
- NULL handling
- IFNULL in MySQL, ISNULL in SQL Server, NVL in Oracle, and COALESCE in all of them. COALESCE is the standard and takes any number of arguments, so it is what a translation should usually produce.
- Data types
- MySQL's TINYINT(1) is a boolean by convention; PostgreSQL has a real BOOLEAN and SQL Server has BIT. TEXT, CLOB, VARCHAR(MAX) and STRING are four names for the same idea, and DATETIME, TIMESTAMP and TIMESTAMPTZ genuinely differ in whether a time zone is carried.
- SQL to MongoDB
- Not a dialect change but a paradigm one. SELECT becomes find or an aggregation pipeline, JOIN becomes $lookup, GROUP BY becomes $group, and WHERE becomes either a filter document or a $match stage depending on where it sits.
Questions about converting SQL
Is the conversion done by AI?
No. It is a deterministic parser and rewriter — the query is parsed into a syntax tree, transformed, and printed in the target dialect. That matters because an AI converter can produce SQL that looks right and quietly changes what the query returns, and you would have no way to tell from the output. The same input here always produces the same output.
Does my SQL get sent to a server?
No. The whole engine is JavaScript running in your browser, so the query never leaves your machine. You can check by opening your browser's network tab while converting, or by disconnecting from the network — it keeps working. This is the reason people paste production schemas into it.
Is there a limit on how many queries I can convert?
No. There is no per-hour cap, no account, no trial, and no paid tier. Nothing is metered because nothing runs on a server that would cost anything to run.
Will it convert a whole schema or just one query?
Both, within reason. Paste a CREATE TABLE statement or several and it will translate the types, key declarations and constraints. What it does not do is move your data — for a full migration you want a dedicated migration tool, and the guides here will tell you so.
What if my pair of databases is not listed?
The 15 pairs below are the ones with a written guide and a worked example. The translator itself handles any combination of the 18 supported dialects — pick the source and target in the tool and it will convert between them, guide or not.