SQL Dialect Converters Compared
You have a query that works in one database and need it in another. Every option here can produce SQL that looks right. The real question is whether you can see what it changed, what it guessed, and what still needs a human decision.
A query that parses is not proof that it means the same thing. Converting SQL is like translating a contract: fluent wording matters less than preserving every obligation. The audit trail is the useful part.
Three fixed queries went through every tool on 8 October 2026.
Q1 — T-SQL to PostgreSQL, the familiar rewrite: SELECT TOP 10 [user_id], ISNULL([name], 'unknown') + ' - ' + [email] AS label FROM [dbo].[users] WHERE [created_at] > GETDATE() ORDER BY [created_at] DESC;
Q2 — MySQL to PostgreSQL, pagination and date formatting: SELECT DATE_FORMAT(created_at, '%Y-%m') AS month, COUNT(*) AS signups FROM users GROUP BY month ORDER BY month DESC LIMIT 10, 20;
Q3 — PostgreSQL to SQL Server, with three constructs that have no clean equivalent: SELECT d::date AS day, jsonb_build_object('day', d::date, 'label', u.name) AS payload FROM generate_series('2026-01-01'::date, '2026-01-31'::date, '1 day') AS d LEFT JOIN users u ON u.name ILIKE '%john%';
Nothing here was executed against a database. The outputs were read, not run, so this is a diagnostic of disclosure behaviour, not an accuracy benchmark. Three queries cannot grade a transpiler. They can show you what each tool does when it meets something it cannot translate — and on that, the results were not close.
Q3 is where the comparison earns its keep. Not one tool produced correct SQL Server output for it. Two said nothing at all. One produced a wrong rewrite and told you exactly which three fragments to check.
SQL Translator
SQL Translator is the n-g.be tool, so the disclosure belongs first: I built it, it is cloud-only, and it uses an OpenAI model rather than a SQL parser. Its purpose is narrower than a migration platform — one query at a time, with a fragment-level account of what changed.
Built by the author of this comparison. SQL is sent to OpenAI.
On Q1 it detected the source dialect without being told, then returned SELECT user_id, COALESCE(name, 'unknown') || ' - ' || email AS label FROM users WHERE created_at > NOW() ORDER BY created_at DESC LIMIT 10; with four numbered before/after entries and a reason for each. It was the only rule-free option that converted T-SQL's + concatenation to PostgreSQL's || — the change two rule-based tools in this comparison left on the floor.
On Q3 it named all three hard constructs in plain words: that SQL Server has no direct equivalent to generate_series, that jsonb_build_object becomes a JSON_QUERY/CONCAT construction, and that ILIKE has no counterpart so LIKE is case-sensitive by default. That is the behaviour the tool exists for.
And its Q3 output is still wrong. The replacement it generated for generate_series is a two-branch UNION ALL, not a recursive CTE: it yields two dates, not thirty-one. Worse, the summary above it called the rewrite "equivalent in terms of functionality". It is not. A tool that flags three constructs and then overstates the result in one sentence has not finished the job.
The hard limits: six dialects, 12,000 characters, one query at a time, no files, dumps or schemas. It neither validates nor executes anything, and your SQL goes to OpenAI. Use it when you want the rewrite itemised — then read the itemisation, including the summary, with the same suspicion you would give the SQL.
Asking ChatGPT or Claude directly
The assistant you already pay for is the honest baseline, and for one query in a dialect you know it is often the fastest place to start. The Q1-Q3 run here was done with Claude; the behaviour is a property of the model class, not of one product, and a different prompt on a different day will not reproduce it exactly.
Independent link. No affiliate relationship, no referral tracking.
Q1 held no surprises: TOP 10 to LIMIT 10, GETDATE() to CURRENT_TIMESTAMP, ISNULL to COALESCE, brackets to double quotes, + to ||.
Q2 showed why schema context matters. MySQL's LIMIT 10, 20 has to become LIMIT 20 OFFSET 10, and DATE_FORMAT maps differently depending on whether the source column is a date, a datetime or a timestamp. The assistant surfaced that choice rather than silently picking one.
Q3 was the useful test, and the assistant gave the most complete answer of anything here — because it knew something the rule-based tools did not. Current SQL Server has GENERATE_SERIES and JSON_OBJECT, so the right rewrite depends on the target version, and jsonb semantics still do not survive the trip. An assistant that reaches for the 2022 function is more useful than a transpiler that reaches for nothing.
The weakness is reproducibility, not capability. The explanation appears because you asked for it, in whatever shape the model felt like, and it is not a fixed record you can diff next month. Input also goes to the model provider, and what happens to it depends on the account and the settings.
sqlglot
sqlglot is the local, rule-based baseline and the only option here that belongs inside your own code. It parses SQL into a tree and generates the target dialect on your machine, with 33 named dialect entries in version 30.21.0.
Independent link. No affiliate relationship, no referral tracking.
On Q2 it was flawless: LIMIT 10, 20 became LIMIT 20 OFFSET 10 and DATE_FORMAT became TO_CHAR(CAST(created_at AS TIMESTAMP), 'YYYY-MM'). Structural rewrites are what a real parser is for, and nothing else here matched it on that query.
On Q1 it handled TOP, ISNULL, the brackets and GETDATE() — and emitted COALESCE("name", 'unknown') + ' - ' + "email". In PostgreSQL, + on text is not concatenation; that query does not run. On Q3 it passed GENERATE_SERIES, JSONB_BUILD_OBJECT and ILIKE straight through into T-SQL output, where none of them exist in that form. Both runs completed with zero warnings.
The project is honest about this boundary in a way its users are not always: sqlglot is a transpiler, not a validator. Default best-effort generation is allowed to emit SQL a real engine rejects, and stricter unsupported-construct handling is a setting you have to choose. The default is silence.
It still earns the highest grade here, because the alternative to silence is configuration you control: strict error handling, captured warnings, conversions that run the same way next quarter, and no query leaving your machine. Use it when SQL cannot go to a vendor, when translation belongs inside a script, or when the same conversion has to be repeatable. Then set the strict flags and test against the target engine anyway.
InventiveHQ SQL Dialect Translator
InventiveHQ's public translator offers nine dialects — including Redshift and Snowflake, which nothing else here covers — auto-detects the source, and converts as you type. Watching the network tab while it ran confirmed what the page claims: the SQL itself never left the browser. The page loads third-party analytics and advertising, but no request carried the query.
Independent link. No affiliate relationship, no referral tracking.
On Q1 it was the most talkative tool in the comparison: twelve numbered translation notes, including one most converters never raise — "T-SQL uses + for both string concatenation and arithmetic. Manual review recommended." That is the correct instinct, and it is worth seeing.
Then it did not do it. The note presents the rewrite as + to ||, and the output SQL still contains +. A note that announces a change it did not apply is worse than no note, because you now believe the output is clean. It also fired a twelfth note about converting 1/0 to TRUE/FALSE for a query containing no boolean literal.
Q3 was the bigger miss. The tool listed "ILIKE operator" under its own detected patterns, then returned two notes — both for ::date casts — and shipped jsonb_build_object, generate_series and ILIKE through to T-SQL untouched and unflagged. The same page promises that constructs without equivalents "will show warnings for manual review". On this query, they did not.
Use it for a fast browser-local sanity check on common dialect differences, where keeping the query off a vendor's server matters more than completeness. Read the notes as a list of things to verify, never as a list of things done.
ExtendsClass SQL to SQL
ExtendsClass covers four database families and publishes a warning most product pages would bury: the converter is in alpha, coverage is partial, and the generated SQL "may no longer match the functionality of the original query". Take that at face value, because the test did.
Independent link. No affiliate relationship, no referral tracking.
On Q1 it reported two conversion details — ISNULL to COALESCE, and GETDATE() to CURRENT_TIME. The second one is a type error. GETDATE() returns a datetime; PostgreSQL's CURRENT_TIME returns a time with time zone and no date at all, so comparing a timestamp column against it is not a narrower query, it is a broken one.
Everything else survived untouched. TOP 10 stayed, the [bracket] identifiers stayed — respaced to [ user_id ] — and + concatenation stayed. None of it is valid PostgreSQL, and none of it was flagged. The output is not a query you edit; it is a query you throw away.
On privacy it is also the opposite of InventiveHQ: pressing Convert posts your SQL to sql-build.php on the vendor's server. That is ordinary for a hosted tool, and worth knowing before you paste production schema into it.
It keeps a point of value anyway, and it is not the conversion. ExtendsClass is the one tool here whose published warning matches its measured behaviour. Every other product page in this comparison promised more than it delivered. If you use it, keep its warning attached to the output.
Datafold SQL Translator
Datafold's 2023 translator was a hosted interface built on SQLGlot, and its value was access to rule-based conversion without writing Python. It appears in this comparison because it is still widely recommended.
Independent link. No affiliate relationship, no referral tracking.
It no longer exists. Checked on 8 October 2026: the public translator URL returns 404 and the dedicated subdomain does not resolve. Only the blog post announcing it is still up. Datafold's current site sells an AI-powered migration service with validation — a different product, aimed at a different buyer, not a free one-query converter.
That is the finding, and it generalises. A hosted free tool is someone else's marketing budget, and it lasts exactly as long as the strategy behind it. Before a converter becomes part of a workflow other people depend on, ask what happens the quarter it is withdrawn — and prefer the option that runs on your own machine for anything you will need twice.
Recommendation
Personal Recommendation
One query, a dialect you know: start with the assistant you already have, and ask it explicitly to list every rewrite, every assumption and every construct with no clean equivalent. The list is the deliverable; the SQL is a draft.
One query, and you need to show your work: use SQL Translator for the itemised before/after, then check the itemisation. On the hard query it named the right three fragments and still generated SQL that does not do the job.
Your SQL cannot leave the building: use sqlglot locally, turn on strict unsupported handling, and capture the warnings. For a one-off browser check with nothing to install, InventiveHQ keeps the query local too.
A whole schema or a data move: none of these. Use AWS Schema Conversion Tool, pgloader or a dump-and-load workflow. A one-query converter is the wrong shape of tool for that job.
The pattern across all six is the same one every rewrite tool has: the dangerous output is not the one that fails, it is the one that looks finished. + left in a PostgreSQL query, ILIKE left in a T-SQL query, CURRENT_TIME where a timestamp belonged — every one of those came back clean and quiet. Keep the original, read the date, null, string, pagination, JSON and table-generating logic yourself, and run the result against representative target data before anyone depends on it. Migrations are control audits, and an AI assistant is a point-of-view tool, not a brain.
