Ist das 100% korrekt? Kann ich den Output direkt nach Production schieben?

**Nein. Result immer reviewen.** Das Tool nutzt ein Set Regex-Regeln, das die häufigsten Unterschiede abdeckt. Komplexe Konstrukte (Stored Procedures, rekursive [[CTE||Common Table Expression, Query mit WITH]], Window-Functions mit OVER) brauchen evtl. manuelle Fixes. Behandle das als solide 80%, nicht 100%.

Was schreibt es genau um?

Die Großen: **auto-incrementierte Keys** (AUTO_INCREMENT / SERIAL / IDENTITY / GENERATED AS IDENTITY), **BOOLEAN-Typen** (BOOL / BIT / TINYINT(1) / NUMBER(1)), **Pagination** (LIMIT/OFFSET vs TOP vs FETCH NEXT), **Text-Typen** (TEXT / LONGTEXT / CLOB / VARCHAR(MAX)), **Zeit-Typen** (TIMESTAMP / DATETIME / DATETIME2 / TIMESTAMPTZ), **Zeit-Funktionen** (NOW / GETDATE / SYSDATE / CURRENT_TIMESTAMP), **String-Concat** (`||` vs CONCAT), **Identifier-Quoting** (Backtick / Bracket / Double-Quote), **MySQL-Trailing-Klauseln** (ENGINE=InnoDB).

Warum existiert LIMIT/OFFSET in MSSQL nicht?

Historisch hatte MSSQL nur `SELECT TOP N` (kein Offset). 2012 kam `OFFSET ... ROWS FETCH NEXT ... ROWS ONLY` dazu, die SQL-Standard-Syntax. Der Konverter nutzt **TOP N**, wenn kein Offset da ist, und **OFFSET/FETCH NEXT**, wenn doch. PostgreSQL/MySQL/SQLite nutzen das freundlichere `LIMIT N OFFSET M`.

Warum wird BOOLEAN in MySQL auf TINYINT(1) gemappt?

**MySQL hat kein natives BOOLEAN.** Das BOOLEAN-Keyword ist ein Alias für TINYINT(1), wobei 0 = false und jeder andere Wert = true. PostgreSQL hat ein echtes BOOLEAN. MSSQL hat BIT (0/1). Oracle nutzt per Konvention NUMBER(1). BigQuery hat BOOLEAN. Der Konverter passt den Typ und die TRUE/FALSE-Literale (zu 1/0) an, wo nötig.

Warum `||` zu CONCAT ändern?

In **PostgreSQL, Oracle, SQLite** ist der Operator `||` String-Concat: `'a' || 'b' = 'ab'`. Aber in **MySQL** ist `||` logisches OR (wie `OR`), also liefert `'a' || 'b'` **0**, nicht "ab". Du brauchst `CONCAT('a', 'b')`. Der Konverter schreibt in beide Richtungen um, je nach Ziel.

Warum nutzt MySQL Backticks und MSSQL eckige Klammern?

Identifier (Tabellen- und Spaltennamen) brauchen manchmal Quoting, z. B. wenn sie ein Leerzeichen enthalten oder mit einem Reserved Word kollidieren. **Standard-SQL** nutzt `"Double Quotes"`. **MySQL** nutzt `Backticks` (weil `"` dort für Strings reserviert ist). **MSSQL** nutzt `[eckige Klammern]` aus historischen Gründen. Der Konverter passt das ans Ziel an.

Konvertiert es IF NOT EXISTS?

PostgreSQL, MySQL, MariaDB und SQLite unterstützen `CREATE TABLE IF NOT EXISTS`. **Oracle nicht** und **MSSQL nicht** für die meisten Objekte. Der Konverter strippt `IF NOT EXISTS` und hinterlässt einen Kommentar, der dich erinnert, es in `IF NOT EXISTS (...) BEGIN ... END` (MSSQL) oder `EXECUTE IMMEDIATE` (Oracle) zu wrappen.

Warum sind meine Kommentare im Output leicht verrutscht?

Die Konvertierung ist regex-basiert und Kommentare sind kontext-sensitiv. Wir versuchen sie zu behalten, aber das Layout kann sich nach dem Reformatieren verschieben. **Schalt Auto-Formatting** in den Optionen aus, wenn du das Ergebnis ohne Layout-Änderung willst.

Schafft es Functions, Trigger und Views?

Teilweise. **Views (CREATE VIEW)** funktionieren meist, weil sie im Grunde ein eingewickeltes SELECT sind. **Functions und Stored Procedures** sind schwieriger, weil jeder Dialekt seine eigene prozedurale Sprache hat (PL/pgSQL, T-SQL, PL/SQL, MySQL-Stored-Procedures). Ihre Bodies werden **nicht voll konvertiert**. Den äußeren Shell hier konvertieren, den Body von Hand umschreiben.

Leckt meine DB irgendwo?

Alles läuft im Browser. Konvertierung ist client-seitig in JavaScript. Keine Query geht an einen Server. Du kannst nach dem Laden vom WiFi gehen, es funktioniert weiter.

SQL-Dialekt-Konverter - kostenlos

Von Dialekt

Zu Dialekt

Ergebnis formatieren

Eingabe (MySQL)

Ausgabe (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;

Angewendete Änderungen8 Änderungen

1
Auto-Increment-Schlüssel
(AUTO_INCREMENT / SERIAL / IDENTITY ...)GENERATED ALWAYS AS IDENTITY
2
MySQL: LIMIT offset, count
LIMIT 0, 20LIMIT 20 OFFSET 0
3
Text-Typ
LONGTEXTTEXT
4
Zeitstempel-Typ
DATETIMETIMESTAMPTZ
5
ENGINE-Klausel (MySQL)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4(dropped, MySQL-specific)
6
Identifier-Quoting
`id`"id"
7
Identifier-Quoting
`email`"email"
8
Identifier-Quoting
`users`"users"

Wozu ein SQL-Dialekt-Konverter?

Jede Datenbank hat ihren eigenen SQL-Flavor. PostgreSQL nutzt `SERIAL` für einen auto-incrementierten Key, MySQL `AUTO_INCREMENT`, MSSQL `IDENTITY(1,1)`, Oracle `GENERATED AS IDENTITY`. Standard-SQL ist theoretisch, in der Praxis hat jeder Vendor seine eigenen Extensions draufgeschraubt.

Du pastest eine Query von einer DB, wählst Quelle und Ziel-Dialekt, und das Tool schreibt die abweichenden Teile um: Spalten-Typen (TINYINT vs BOOLEAN vs BIT vs NUMBER(1)), auto-incrementierte Keys, Pagination (`LIMIT/OFFSET` vs `TOP` vs `FETCH NEXT`), Zeit-Funktionen (`NOW()` vs `GETDATE()` vs `SYSDATE`), String-Concat (`||` vs `CONCAT()`), Identifier-Quoting (`` `id` `` vs `[id]` vs `"id"`).

Rechts siehst du die Liste der angewandten Änderungen mit kurzer Begründung. Keine Magie, nur ein anständiges Regelwerk, das etwa 80% einfacher Schema-Portierungen abdeckt.

So nutzt du das Tool

Quell-Dialekt (woher die Query stammt) und Ziel-Dialekt (wo sie laufen soll) wählen.

Dein SQL ins linke Panel pasten. Kann `CREATE TABLE`, `SELECT`, `INSERT` sein, was auch immer.

Rechts kriegst du das konvertierte Ergebnis, automatisch für den Ziel-Dialekt formatiert.

Drunter die Liste der gemachten Änderungen: jede Regel mit "vorher / nachher"-Diff und kurzem Label.

Ergebnis mit Copy kopieren. Dann die Logik gegenprüfen (Regex kann nicht alles, manchmal sind manuelle Tweaks nötig).

Swap-Arrows drehen Quelle und Ziel. Praktisch für Konvertierung in beide Richtungen.

Wann das nützlich ist

Klassische Szenarien:

Von MySQL zu PostgreSQL migrieren. Der Klassiker: die Firma ist gewachsen, MySQL reicht nicht, du gehst zu Postgres. Schema muss umgeschrieben werden. Dieses Tool macht 80% der Drecksarbeit.
Zwei Datenbanken in einer ORM unterstützen. Du arbeitest mit Prisma oder Drizzle, der Kunde läuft auf MSSQL, dein lokales Dev ist PostgreSQL. Du brauchst zwei Versionen des Init-Skripts.
BigQuery-Tabellen aus einer Operativ-DB bauen. Das MySQL-Schema muss an BigQuery angepasst werden, das kein AUTO_INCREMENT hat und viele Typ-Unterschiede.
Code-Review einer Query von einem Kollegen, der gegen eine andere Engine schreibt. Schneller Check, ob sie auf deiner DB läuft.
Dialekt-Unterschiede lernen. Eine simple Query pasten, den Ziel-Dialekt umschalten, sehen was sich ändert. Besser als trockene Doku lesen.
Portabilitäts-Check eines bestehenden Schemas. Die Konvertierung hebt hervor, wo du Vendor-spezifische Konstrukte nutzt.

Nach der Konvertierung kannst du den Output mit unserem SQL-Formatter formatieren. Brauchst du stattdessen ein ORM-Schema? Schau den SQL-zu-ORM-Konverter.

Fragen und Antworten

Nein. Result immer reviewen. Das Tool nutzt ein Set Regex-Regeln, das die häufigsten Unterschiede abdeckt. Komplexe Konstrukte (Stored Procedures, rekursive CTE, Window-Functions mit OVER) brauchen evtl. manuelle Fixes. Behandle das als solide 80%, nicht 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;

Wozu ein SQL-Dialekt-Konverter?

Rechts siehst du die Liste der angewandten Änderungen mit kurzer Begründung. Keine Magie, nur ein anständiges Regelwerk, das etwa 80% einfacher Schema-Portierungen abdeckt.

So nutzt du das Tool

Quell-Dialekt (woher die Query stammt) und Ziel-Dialekt (wo sie laufen soll) wählen.

Dein SQL ins linke Panel pasten. Kann `CREATE TABLE`, `SELECT`, `INSERT` sein, was auch immer.

Rechts kriegst du das konvertierte Ergebnis, automatisch für den Ziel-Dialekt formatiert.

Drunter die Liste der gemachten Änderungen: jede Regel mit "vorher / nachher"-Diff und kurzem Label.

Ergebnis mit Copy kopieren. Dann die Logik gegenprüfen (Regex kann nicht alles, manchmal sind manuelle Tweaks nötig).

Swap-Arrows drehen Quelle und Ziel. Praktisch für Konvertierung in beide Richtungen.

Wann das nützlich ist

Klassische Szenarien:

Von MySQL zu PostgreSQL migrieren. Der Klassiker: die Firma ist gewachsen, MySQL reicht nicht, du gehst zu Postgres. Schema muss umgeschrieben werden. Dieses Tool macht 80% der Drecksarbeit.
Zwei Datenbanken in einer ORM unterstützen. Du arbeitest mit Prisma oder Drizzle, der Kunde läuft auf MSSQL, dein lokales Dev ist PostgreSQL. Du brauchst zwei Versionen des Init-Skripts.
BigQuery-Tabellen aus einer Operativ-DB bauen. Das MySQL-Schema muss an BigQuery angepasst werden, das kein AUTO_INCREMENT hat und viele Typ-Unterschiede.
Code-Review einer Query von einem Kollegen, der gegen eine andere Engine schreibt. Schneller Check, ob sie auf deiner DB läuft.
Dialekt-Unterschiede lernen. Eine simple Query pasten, den Ziel-Dialekt umschalten, sehen was sich ändert. Besser als trockene Doku lesen.
Portabilitäts-Check eines bestehenden Schemas. Die Konvertierung hebt hervor, wo du Vendor-spezifische Konstrukte nutzt.

Nach der Konvertierung kannst du den Output mit unserem SQL-Formatter formatieren. Brauchst du stattdessen ein ORM-Schema? Schau den SQL-zu-ORM-Konverter.

Fragen und Antworten

SQL-Dialekt-Konverter

Wozu ein SQL-Dialekt-Konverter?

So nutzt du das Tool

Wann das nützlich ist

Fragen und Antworten

Passende Tools

SQL-Formatter

SQL zu ORM Konverter

DBML zu SQL

DB Connection-String Parser

SQL-Dialekt-Konverter

Wozu ein SQL-Dialekt-Konverter?

So nutzt du das Tool

Wann das nützlich ist

Fragen und Antworten

Passende Tools

SQL-Formatter

SQL zu ORM Konverter

DBML zu SQL

DB Connection-String Parser