SQL Dialect Translator

Overview

Paste a SQL statement and pick source and target dialects (PostgreSQL, MySQL, SQL Server, SQLite). The translator rewrites dialect-specific syntax - identifier quoting, LIMIT vs TOP, RETURNING clauses, IF EXISTS placement, date functions - so the query runs on the new engine.

It's for developers porting queries between databases, writing migrations across stacks, or maintaining a codebase that targets multiple SQL flavours. Reach for it when migrating off MySQL to Postgres, when a CI fixture in SQLite needs a hand-edited Postgres equivalent, or when reverse-engineering a vendor query.

How it works

Each SQL dialect has its own grammar - they share the SQL-92 / SQL:2011 core but diverge on countless surface details. The translator parses against a common AST and re-emits using dialect-specific syntax rules: PostgreSQL uses "-quoted identifiers and LIMIT n OFFSET m; SQL Server uses [] brackets and TOP n; MySQL uses backticks and supports both; SQLite tracks PostgreSQL most closely.

Coverage focuses on the common cases: SELECT/UPDATE/INSERT/DELETE with LIMIT/OFFSET/RETURNING, date and string function names, identifier quoting, and CREATE TABLE column types. Stored procedures and dialect-specific extensions (window-function syntax variants, JSON functions) need manual review.

Examples

• LIMIT/OFFSET:

  -- PostgreSQL / MySQL / SQLite
  SELECT * FROM users LIMIT 10 OFFSET 20;
  
  -- SQL Server
  SELECT * FROM users ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
  

• Identifier quoting:

  -- PostgreSQL:  "user"."name"
  -- SQL Server:  [user].[name]
  -- MySQL:       `user`.`name`
  

• INSERT ... RETURNING:

  -- PostgreSQL
  INSERT INTO posts (title) VALUES ('x') RETURNING id;
  
  -- SQL Server
  INSERT INTO posts (title) OUTPUT INSERTED.id VALUES ('x');
  

• Current date function:

  -- PostgreSQL:  CURRENT_DATE
  -- SQL Server:  GETDATE()
  -- MySQL:       CURDATE()
  

FAQ

Does it translate every query?

No - the translator handles the syntactic surface. Dialect-specific behaviour (transaction isolation, lock semantics, exact NULL handling) needs developer review.

What about JSON columns and functions?

All four engines support JSON but with different function names (json_extract, JSON_VALUE, ->). The translator maps the most-common forms; complex JSON paths may need manual translation.

Can I round-trip without loss?

Round-tripping (A -> B -> A) is lossless for well-supported syntax. Edge cases may not survive - always test the translated query before relying on it.

Does it handle stored procedures?

T-SQL stored procedures and PL/pgSQL functions have very different semantics. The translator can rewrite the surface syntax but won't translate procedural control flow reliably.

Try SQL Dialect Translator