b2KIT

SQL Dialect Converter

Convert SQL between dialects: PostgreSQL, MySQL, SQLite, SQL Server, and Oracle syntax.

Tested tool guide Tested browser tools Checked August 16, 2026

What SQL Dialect Converter does, with a checked example

Five SQL engines agree on the broad shape of a SELECT, but each spells the details differently. MySQL writes LIMIT at the end, SQL Server puts TOP in the select list, PostgreSQL casts with ::, Oracle numbers rows with ROWNUM. This tool rewrites a query between PostgreSQL, MySQL, SQLite, SQL Server, and Oracle so it runs unchanged on the target engine. What surprises people most: a converted query that parses cleanly is not a query that behaves identically, because AUTO_INCREMENT, SERIAL, and IDENTITY auto-number rows in subtly different ways. The conversion runs in your browser; pasted queries are not uploaded.

Worked example

A concrete input and expected output from the current implementation.

Input

SELECT id, name
FROM customers
ORDER BY name
LIMIT 5;

Expected output

SELECT TOP (5) id, name
FROM customers
ORDER BY name;

MySQL and SQLite place the row limit at the end with LIMIT. SQL Server has no LIMIT clause, so the limit moves into the select list as TOP (n) and the ORDER BY is kept, because it determines which five rows are returned. TOP without ORDER BY would parse but return arbitrary rows.

How the result is produced

1

Statement-by-statement rewrite

Each statement in the pasted text is parsed and rebuilt in the target dialect. LIMIT and OFFSET become TOP, OFFSET ... FETCH, or a ROWNUM filter depending on the target; identifier quoting moves between backticks, double quotes, and square brackets; string concatenation switches between CONCAT, ||, and +; AUTO_INCREMENT, SERIAL, IDENTITY, and identity columns map to the target's auto-numbering clause. Statements it cannot parse are reported rather than silently rewritten.

2

Type and function mapping

Data types and functions are translated where a direct equivalent exists: INT to NUMBER, IFNULL to COALESCE, MySQL's NOW() to SQL Server's GETDATE(), GROUP_CONCAT to STRING_AGG or LISTAGG. Where no equivalent exists, the converter keeps the original text and flags it for review rather than guessing. It handles standalone statements and queries; stored procedures, triggers, and procedural blocks are outside its scope, as is tuning the rewritten query for performance.

Good uses

  • Porting a MySQL-backed app to SQL Server: LIMIT becomes TOP, backtick quoting becomes standard double quotes, and NOW() becomes GETDATE(), so each query runs as-is on the new engine.
  • Pulling a report query into SQLite for local testing, where MySQL-isms like backticks, ON DUPLICATE KEY UPDATE, and ENGINE clauses are rejected.
  • Keeping one PostgreSQL source query and producing an Oracle-flavored copy for a client or environment that runs both engines.

Limits and checks

  • Valid syntax is not identical behavior. LIMIT or TOP without ORDER BY returns arbitrary rows, NULL comparisons follow ANSI rules in SQL Server but historically differed in MySQL, and collation changes string ordering. Converted output needs a run against the real database, not a read-through.
  • Type mapping is by name, not by semantics. VARCHAR, TEXT, and NVARCHAR differ in length limits, Unicode support, and collation across engines, so a statement that parses cleanly may still store, sort, or truncate data differently.
  • Function translation is approximate where no exact equivalent exists. GROUP_CONCAT, STRING_AGG, and LISTAGG differ in separator handling and ordering guarantees, and an unmapped function may pass through unchanged rather than erroring.

Common questions

Can I paste an entire stored procedure or trigger?

No. The tool converts individual statements and queries. T-SQL batches with variables, PL/pgSQL functions, and Oracle PL/SQL blocks are not converted; split the script into single statements, convert each one, and reassemble the procedural parts by hand.

Will the converted query return exactly the same results?

Not guaranteed. The rewrite targets syntax, and syntax differences can change results: TOP or LIMIT without ORDER BY selects rows arbitrarily, collations change string comparison, and NULL semantics vary between engines. Treat the output as a starting point and test it against the target database with realistic data.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools