Is this 100% correct? Can I push the output straight to production?

**No. Always review the result.** The tool uses a set of regex rules covering the most common differences. Complex constructs (stored procedures, recursive [[CTE||Common Table Expression, a query starting with WITH]], window functions with OVER) may need manual fixes. Treat this as a solid 80%, not 100%.

What exactly does it rewrite?

The big ones: **auto-incremented keys** (AUTO_INCREMENT / SERIAL / IDENTITY / GENERATED AS IDENTITY), **BOOLEAN types** (BOOL / BIT / TINYINT(1) / NUMBER(1)), **pagination** (LIMIT/OFFSET vs TOP vs FETCH NEXT), **text types** (TEXT / LONGTEXT / CLOB / VARCHAR(MAX)), **time types** (TIMESTAMP / DATETIME / DATETIME2 / TIMESTAMPTZ), **time functions** (NOW / GETDATE / SYSDATE / CURRENT_TIMESTAMP), **string concat** (`||` vs CONCAT), **identifier quoting** (backtick / bracket / double-quote), **MySQL trailing clauses** (ENGINE=InnoDB).

Why does LIMIT/OFFSET not exist in MSSQL?

Historically MSSQL only had `SELECT TOP N` (no offset). In 2012 it added `OFFSET ... ROWS FETCH NEXT ... ROWS ONLY`, the SQL standard syntax. The converter uses **TOP N** when there is no offset and **OFFSET/FETCH NEXT** when there is. PostgreSQL/MySQL/SQLite use the friendlier `LIMIT N OFFSET M`.

Why is BOOLEAN mapped to TINYINT(1) in MySQL?

**MySQL has no native BOOLEAN.** The BOOLEAN keyword is an alias for TINYINT(1), where 0 = false and any other value = true. PostgreSQL has a real BOOLEAN. MSSQL has BIT (0/1). Oracle uses NUMBER(1) by convention. BigQuery has BOOLEAN. The converter adjusts the type and the TRUE/FALSE literals (to 1/0) where needed.

Why change `||` to CONCAT?

In **PostgreSQL, Oracle, SQLite** the `||` operator is string concatenation: `'a' || 'b' = 'ab'`. But in **MySQL** `||` is logical OR (same as `OR`), so `'a' || 'b'` returns **0**, not "ab". You need `CONCAT('a', 'b')`. The converter rewrites in both directions depending on the target.

Why does MySQL use backticks and MSSQL use square brackets?

Identifiers (table and column names) sometimes need quoting, e.g. when they contain a space or clash with a reserved word. **Standard SQL** uses `"double quotes"`. **MySQL** uses `backticks` (because `"` is reserved for strings there). **MSSQL** uses `[square brackets]` for historical reasons. The converter adjusts to the target style.

Does it convert IF NOT EXISTS?

PostgreSQL, MySQL, MariaDB, and SQLite support `CREATE TABLE IF NOT EXISTS`. **Oracle does not** support this syntax and **MSSQL does not** for most objects. The converter strips `IF NOT EXISTS` and leaves a comment reminding you to wrap it in `IF NOT EXISTS (...) BEGIN ... END` on MSSQL or `EXECUTE IMMEDIATE` on Oracle.

Why are my comments slightly out of place in the output?

Conversion is regex-based and comments are context-sensitive. We try to keep them, but the layout may shift after reformatting. **Turn off auto-formatting** in the options if you want the result with no layout change.

Does it handle functions, triggers, and views?

Partially. **Views (CREATE VIEW)** usually work because they are essentially a wrapped SELECT. **Functions and stored procedures** are trickier because each dialect has its own procedural language (PL/pgSQL, T-SQL, PL/SQL, MySQL stored procedures). Their bodies are **not fully converted**. Convert the outer shell here, rewrite the body by hand.

Does my database leak anywhere?

Everything runs in your browser. Conversion is client-side in JavaScript. No queries go to a server. You can disconnect from WiFi after the page loads and it will still work.

SQL Dialect Converter - free

From dialect

To dialect

Format result

Input (MySQL)

Output (PostgreSQL)

CREATE TABLE IF NOT EXISTS users (
  id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  is_active TINYINT (1) NOT NULL DEFAULT 1,
  bio TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

SELECT
  "id",
  "email"
FROM
  "users"
WHERE
  is_active = TRUE
LIMIT
  20
OFFSET
  0;

Applied changes8 changes

1
Auto-increment key
(AUTO_INCREMENT / SERIAL / IDENTITY ...)GENERATED ALWAYS AS IDENTITY
2
MySQL LIMIT offset, count
LIMIT 0, 20LIMIT 20 OFFSET 0
3
Text type
LONGTEXTTEXT
4
Timestamp type
DATETIMETIMESTAMPTZ
5
ENGINE clause (MySQL)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4(dropped, MySQL-specific)
6
Identifier quoting
`id`"id"
7
Identifier quoting
`email`"email"
8
Identifier quoting
`users`"users"

Why a SQL dialect converter?

Every database has its own flavor of SQL. PostgreSQL uses `SERIAL` for an auto-incremented key, MySQL uses `AUTO_INCREMENT`, MSSQL uses `IDENTITY(1,1)`, Oracle uses `GENERATED AS IDENTITY`. Standard SQL is theoretical, in practice every vendor bolted on their own extensions.

You paste a query from one database, pick the source and target dialect, and the tool rewrites the bits that differ: column types (TINYINT vs BOOLEAN vs BIT vs NUMBER(1)), auto-incremented keys, pagination (`LIMIT/OFFSET` vs `TOP` vs `FETCH NEXT`), time functions (`NOW()` vs `GETDATE()` vs `SYSDATE`), string concatenation (`||` vs `CONCAT()`), identifier quoting (`` `id` `` vs `[id]` vs `"id"`).

On the right you see the list of changes applied with a short reason. No magic, just a decent ruleset that covers about 80% of porting simple schemas.

How to use it

Pick the source dialect (where the query is from) and the target dialect (where you want it to run).

Paste your SQL into the left panel. Can be `CREATE TABLE`, `SELECT`, `INSERT`, whatever.

On the right you get the converted result, automatically formatted for the target dialect.

Below you see the list of changes made: each rule with a "before / after" diff and a short label.

Copy the result with the Copy button. Then sanity-check the logic (regex cannot do everything, sometimes manual tweaks are needed).

Use the swap arrows to flip source and target. Handy when you want to convert in both directions.

When this is useful

Common scenarios:

Migrating from MySQL to PostgreSQL. The classic: the company grew, MySQL is not enough, you move to Postgres. The schema needs to be rewritten. This tool handles 80% of the grunt work.
Supporting two databases in one ORM. You work with Prisma or Drizzle, the client runs MSSQL, your local dev is PostgreSQL. You need two versions of the init script.
Building BigQuery tables from an operational database. The MySQL schema needs to be adapted to BigQuery, which has no AUTO_INCREMENT and many type differences.
Code review of a query from a coworker who writes against another engine. Quick sanity check whether it will run on your database.
Learning differences between dialects. Paste a simple query, toggle the target dialect, watch what changes. Better than reading dry docs.
Portability check of an existing schema. The conversion highlights where you use vendor-specific constructs.

After conversion, format the output with our SQL formatter. Want an ORM schema instead? See the SQL to ORM converter.

Questions and answers

No. Always review the result. The tool uses a set of regex rules covering the most common differences. Complex constructs (stored procedures, recursive CTE, window functions with OVER) may need manual fixes. Treat this as a solid 80%, not 100%.

CREATE TABLE IF NOT EXISTS users ( id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, email VARCHAR(255) NOT NULL, is_active TINYINT (1) NOT NULL DEFAULT 1, bio TEXT, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); SELECT "id", "email" FROM "users" WHERE is_active = TRUE LIMIT 20 OFFSET 0;

Why a SQL dialect converter?

On the right you see the list of changes applied with a short reason. No magic, just a decent ruleset that covers about 80% of porting simple schemas.

How to use it

Pick the source dialect (where the query is from) and the target dialect (where you want it to run).

Paste your SQL into the left panel. Can be `CREATE TABLE`, `SELECT`, `INSERT`, whatever.

On the right you get the converted result, automatically formatted for the target dialect.

Below you see the list of changes made: each rule with a "before / after" diff and a short label.

Copy the result with the Copy button. Then sanity-check the logic (regex cannot do everything, sometimes manual tweaks are needed).

Use the swap arrows to flip source and target. Handy when you want to convert in both directions.

When this is useful

Common scenarios:

Migrating from MySQL to PostgreSQL. The classic: the company grew, MySQL is not enough, you move to Postgres. The schema needs to be rewritten. This tool handles 80% of the grunt work.
Supporting two databases in one ORM. You work with Prisma or Drizzle, the client runs MSSQL, your local dev is PostgreSQL. You need two versions of the init script.
Building BigQuery tables from an operational database. The MySQL schema needs to be adapted to BigQuery, which has no AUTO_INCREMENT and many type differences.
Code review of a query from a coworker who writes against another engine. Quick sanity check whether it will run on your database.
Learning differences between dialects. Paste a simple query, toggle the target dialect, watch what changes. Better than reading dry docs.
Portability check of an existing schema. The conversion highlights where you use vendor-specific constructs.

After conversion, format the output with our SQL formatter. Want an ORM schema instead? See the SQL to ORM converter.

Questions and answers

SQL Dialect Converter

Why a SQL dialect converter?

How to use it

When this is useful

Questions and answers

Related tools

SQL Formatter

SQL to ORM Converter

DBML to SQL Converter

Database Connection String Parser

SQL Dialect Converter

Why a SQL dialect converter?

How to use it

When this is useful

Questions and answers

Related tools

SQL Formatter

SQL to ORM Converter

DBML to SQL Converter

Database Connection String Parser