How to Convert SQL Between Dialects: Step-by-Step Tutorial

This tutorial walks you through using the SQL Dialect Converter to translate queries between MySQL, PostgreSQL, SQL Server (T-SQL), SQLite, and Oracle. You'll see concrete examples of each conversion type and learn how to interpret the change log, warnings, and confidence score.

Step 1: Open the Tool

Navigate to the SQL Dialect Converter. You'll see two panes: the left pane is for your input SQL, and the right pane shows the converted output. Above each pane is a dialect dropdown.

Step 2: Select Your Dialects

Choose the source dialect from the left dropdown (the dialect your SQL is currently written in) and the target dialect from the right dropdown (the dialect you want to convert to). For example, if you're migrating from MySQL to PostgreSQL, select "MySQL" on the left and "PostgreSQL" on the right.

Step 3: Enter Your SQL

Paste your SQL into the input pane, or drag and drop a .sql file. You can also use the "Load Example" dropdown to try a pre-built sample query. Let's start with a MySQL query that uses several dialect-specific features:

SELECT
  u.`name`,
  IFNULL(u.`email`, 'N/A') AS email,
  NOW() AS report_date
FROM `users` u
WHERE u.`active` = TRUE
ORDER BY u.`name`
LIMIT 10;

Step 4: Click "Convert SQL"

Click the blue Convert SQL button (or press Ctrl+Enter). The converted output appears in the right pane. For MySQL → PostgreSQL, the output would look like:

SELECT
  u."name",
  COALESCE(u."email", 'N/A') AS email,
  CURRENT_TIMESTAMP AS report_date
FROM "users" u
WHERE u."active" = TRUE
ORDER BY u."name"
LIMIT 10;

Notice the changes: backtick identifiers became double-quoted, IFNULL became COALESCE, and NOW() became CURRENT_TIMESTAMP. The LIMIT clause stayed the same because PostgreSQL supports it natively.

Step 5: Review the Changes Tab

Below the converter, the Changes tab lists every transformation that was applied. Each entry shows the category (Function, Clause, Quoting, DDL), the original and replacement values, and how many times the change was applied. This is your audit trail — it lets you verify that every substitution is correct for your use case.

Step 6: Check the Warnings Tab

The Warnings tab flags anything that couldn't be converted automatically or that may have semantic implications. For example, if you convert string concatenation from PostgreSQL (||) to SQL Server (+), you'll see a warning about NULL behavior differences. Each warning includes a code, a description, and a line number when available.

Step 7: Read the Confidence Score

The confidence bar shows how completely the conversion succeeded. A score above 80% means most constructs were handled cleanly. Scores between 50-80% indicate some warnings or fallback conversions. Below 50% suggests significant manual review is needed.

Example: MySQL to SQL Server (LIMIT and Functions)

Input (MySQL):

SELECT NOW(), IFNULL(a, b) FROM t LIMIT 5;

Output (SQL Server):

SELECT GETDATE(), ISNULL(a, b) FROM t OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY;

Changes: NOW() → GETDATE(), IFNULL → ISNULL, LIMIT 5 → OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY.

Example: CREATE TABLE with Auto-Increment

Input (MySQL):

CREATE TABLE orders (
  id INT AUTO_INCREMENT PRIMARY KEY,
  total DECIMAL(10,2),
  created_at DATETIME DEFAULT NOW()
);

Output (PostgreSQL):

CREATE TABLE orders (
  id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  total DECIMAL(10,2),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Example: String Concatenation with NULL Warning

Input (PostgreSQL):

SELECT first_name || ' ' || last_name AS full_name
FROM employees;

Output (SQL Server):

SELECT first_name + ' ' + last_name AS full_name
FROM employees;

Warning: POTENTIAL_SEMANTIC_CHANGE_NULL_CONCAT — SQL Server + returns NULL if either operand is NULL. Consider wrapping with ISNULL().

Using Advanced Options

Click Advanced Options to customize the conversion:

• Normalize keywords to UPPERCASE — transforms all SQL keywords to uppercase for consistency.
• Preserve identifier quoting — keeps the original quoting style instead of converting to the target dialect's convention.
• Fallback mode — if the parser encounters something it can't handle, it falls back to token-based conversion instead of stopping.
• Format output — applies basic formatting to the output for readability.
• Strict mode — stops on unsupported constructs instead of attempting best-effort conversion.

Using the Diff Viewer

Click Open Diff to see a side-by-side comparison of your input and output. Changed lines are highlighted, making it easy to spot exactly what was modified. This is especially useful for large queries where scanning the change log line by line would be tedious.

Downloading Your Result

Click Download .sql to save the converted output as a file. The filename follows the pattern converted_mysql_to_postgres.sql, making it easy to track which conversion was applied.