Est-ce correct à 100 % ? Puis-je pousser la sortie directement en production ?

**Non. Relisez toujours le résultat.** L'outil utilise un jeu de règles regex couvrant les différences les plus courantes. Les constructions complexes (procédures stockées, [[CTE||Common Table Expression, requête qui commence par WITH]] récursives, fonctions fenêtres avec OVER) peuvent nécessiter des corrections manuelles. Considérez ça comme un bon 80 %, pas 100 %.

Que réécrit-il exactement ?

Les gros morceaux : **clés auto-incrémentées** (AUTO_INCREMENT / SERIAL / IDENTITY / GENERATED AS IDENTITY), **types BOOLEAN** (BOOL / BIT / TINYINT(1) / NUMBER(1)), **pagination** (LIMIT/OFFSET vs TOP vs FETCH NEXT), **types texte** (TEXT / LONGTEXT / CLOB / VARCHAR(MAX)), **types temps** (TIMESTAMP / DATETIME / DATETIME2 / TIMESTAMPTZ), **fonctions de temps** (NOW / GETDATE / SYSDATE / CURRENT_TIMESTAMP), **concat de chaînes** (`||` vs CONCAT), **quoting d'identifiants** (backtick / bracket / double-quote), **clauses MySQL de fin** (ENGINE=InnoDB).

Pourquoi LIMIT/OFFSET n'existe-t-il pas dans MSSQL ?

Historiquement, MSSQL n'avait que `SELECT TOP N` (sans offset). En 2012, il a ajouté `OFFSET ... ROWS FETCH NEXT ... ROWS ONLY`, la syntaxe du SQL standard. Le convertisseur utilise **TOP N** quand il n'y a pas d'offset et **OFFSET/FETCH NEXT** quand il y en a un. PostgreSQL/MySQL/SQLite utilisent le plus convivial `LIMIT N OFFSET M`.

Pourquoi BOOLEAN est-il mappé à TINYINT(1) en MySQL ?

**MySQL n'a pas de BOOLEAN natif.** Le mot-clé BOOLEAN est un alias pour TINYINT(1), où 0 = false et toute autre valeur = true. PostgreSQL a un vrai BOOLEAN. MSSQL a BIT (0/1). Oracle utilise NUMBER(1) par convention. BigQuery a BOOLEAN. Le convertisseur ajuste le type et les littéraux TRUE/FALSE (en 1/0) là où c'est nécessaire.

Pourquoi changer `||` en CONCAT ?

En **PostgreSQL, Oracle, SQLite**, l'opérateur `||` est la concaténation de chaînes : `'a' || 'b' = 'ab'`. Mais en **MySQL**, `||` est un OU logique (comme `OR`), donc `'a' || 'b'` renvoie **0**, pas « ab ». Il faut `CONCAT('a', 'b')`. Le convertisseur réécrit dans les deux sens selon la cible.

Pourquoi MySQL utilise des backticks et MSSQL des crochets ?

Les identifiants (noms de table et de colonne) nécessitent parfois un quoting, par exemple quand ils contiennent un espace ou heurtent un mot réservé. Le **SQL standard** utilise `"guillemets doubles"`. **MySQL** utilise les `backticks` (parce que `"` est réservé aux chaînes chez lui). **MSSQL** utilise les `[crochets]` pour des raisons historiques. Le convertisseur s'ajuste au style de la cible.

Convertit-il IF NOT EXISTS ?

PostgreSQL, MySQL, MariaDB et SQLite prennent en charge `CREATE TABLE IF NOT EXISTS`. **Oracle ne le prend pas** en charge et **MSSQL ne le prend pas** pour la plupart des objets. Le convertisseur retire `IF NOT EXISTS` et laisse un commentaire vous rappelant de l'envelopper dans `IF NOT EXISTS (...) BEGIN ... END` sur MSSQL ou `EXECUTE IMMEDIATE` sur Oracle.

Pourquoi mes commentaires sont-ils légèrement décalés dans la sortie ?

La conversion est basée sur des regex et les commentaires sont sensibles au contexte. Nous essayons de les garder, mais la mise en page peut bouger après reformatage. **Désactivez l'auto-formatage** dans les options si vous voulez le résultat sans changement de layout.

Gère-t-il les fonctions, triggers et vues ?

En partie. Les **vues (CREATE VIEW)** fonctionnent généralement parce que ce sont essentiellement des SELECT enveloppés. Les **fonctions et procédures stockées** sont plus délicates car chaque dialecte a son propre langage procédural (PL/pgSQL, T-SQL, PL/SQL, procédures stockées MySQL). Leurs corps **ne sont pas entièrement convertis**. Convertissez l'enveloppe ici, réécrivez le corps à la main.

Ma base de données fuit-elle quelque part ?

Tout tourne dans votre navigateur. La conversion est côté client en JavaScript. Aucune requête ne part vers un serveur. Vous pouvez couper le wifi après chargement de la page et ça fonctionnera toujours.

Convertisseur dialectes SQL - gratuit

From dialect

To dialect

Format result

SQL source (MySQL)

SQL converti (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 changements

1
Clé auto-incrémentée
(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
Clause ENGINE (MySQL)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4(dropped, MySQL-specific)
6
Quotes d'identificateurs
`id`"id"
7
Quotes d'identificateurs
`email`"email"
8
Quotes d'identificateurs
`users`"users"

Pourquoi un convertisseur de dialectes SQL ?

Chaque base a sa propre saveur de SQL. PostgreSQL utilise `SERIAL` pour une clé auto-incrémentée, MySQL utilise `AUTO_INCREMENT`, MSSQL utilise `IDENTITY(1,1)`, Oracle utilise `GENERATED AS IDENTITY`. Le SQL standard est théorique : en pratique, chaque éditeur a greffé ses propres extensions.

Vous collez une requête issue d'une base, vous choisissez le dialecte source et le dialecte cible, et l'outil réécrit ce qui diffère : types de colonnes (TINYINT vs BOOLEAN vs BIT vs NUMBER(1)), clés auto-incrémentées, pagination (`LIMIT/OFFSET` vs `TOP` vs `FETCH NEXT`), fonctions de temps (`NOW()` vs `GETDATE()` vs `SYSDATE`), concaténation de chaînes (`||` vs `CONCAT()`), quoting d'identifiants (`` `id` `` vs `[id]` vs `"id"`).

À droite, vous voyez la liste des changements appliqués avec une brève raison. Pas de magie, juste un jeu de règles correct qui couvre environ 80 % du portage de schémas simples.

Mode d'emploi

Choisissez le dialecte source (d'où vient la requête) et le dialecte cible (où vous voulez qu'elle tourne).

Collez votre SQL dans le panneau de gauche. Cela peut être un `CREATE TABLE`, `SELECT`, `INSERT`, peu importe.

À droite, vous obtenez le résultat converti, automatiquement formaté pour le dialecte cible.

En dessous, vous voyez la liste des changements effectués : chaque règle avec un diff « avant / après » et une courte étiquette.

Copiez le résultat avec le bouton Copier. Puis vérifiez la logique (les regex ne peuvent pas tout faire, des ajustements manuels sont parfois nécessaires).

Utilisez les flèches d'inversion pour permuter source et cible. Pratique pour convertir dans les deux sens.

Quand c'est utile

Scénarios courants :

Migration de MySQL vers PostgreSQL. Le classique : l'entreprise grandit, MySQL ne suffit plus, on passe à Postgres. Le schéma doit être réécrit. Cet outil prend en charge 80 % du travail ingrat.
Support de deux bases dans un seul ORM. Vous travaillez avec Prisma ou Drizzle, le client tourne sous MSSQL, votre dev local est PostgreSQL. Il vous faut deux versions du script d'init.
Construction de tables BigQuery depuis une base opérationnelle. Le schéma MySQL doit être adapté à BigQuery, qui n'a pas d'AUTO_INCREMENT et présente de nombreuses différences de types.
Revue de code d'une requête venant d'un collègue qui écrit pour un autre moteur. Vérification rapide qu'elle tournera sur votre base.
Apprendre les différences entre dialectes. Collez une requête simple, changez le dialecte cible, observez ce qui change. Mieux que de lire une doc aride.
Vérification de portabilité d'un schéma existant. La conversion met en évidence les endroits où vous utilisez des constructions spécifiques à un éditeur.

Après conversion, formatez la sortie avec notre formateur SQL. Vous voulez un schéma ORM à la place ? Voir le convertisseur SQL vers ORM.

Questions et réponses

Non. Relisez toujours le résultat. L'outil utilise un jeu de règles regex couvrant les différences les plus courantes. Les constructions complexes (procédures stockées, CTE récursives, fonctions fenêtres avec OVER) peuvent nécessiter des corrections manuelles. Considérez ça comme un bon 80 %, pas 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;

Pourquoi un convertisseur de dialectes SQL ?

À droite, vous voyez la liste des changements appliqués avec une brève raison. Pas de magie, juste un jeu de règles correct qui couvre environ 80 % du portage de schémas simples.

Mode d'emploi

Choisissez le dialecte source (d'où vient la requête) et le dialecte cible (où vous voulez qu'elle tourne).

Collez votre SQL dans le panneau de gauche. Cela peut être un `CREATE TABLE`, `SELECT`, `INSERT`, peu importe.

À droite, vous obtenez le résultat converti, automatiquement formaté pour le dialecte cible.

En dessous, vous voyez la liste des changements effectués : chaque règle avec un diff « avant / après » et une courte étiquette.

Copiez le résultat avec le bouton Copier. Puis vérifiez la logique (les regex ne peuvent pas tout faire, des ajustements manuels sont parfois nécessaires).

Utilisez les flèches d'inversion pour permuter source et cible. Pratique pour convertir dans les deux sens.

Quand c'est utile

Scénarios courants :

Migration de MySQL vers PostgreSQL. Le classique : l'entreprise grandit, MySQL ne suffit plus, on passe à Postgres. Le schéma doit être réécrit. Cet outil prend en charge 80 % du travail ingrat.
Support de deux bases dans un seul ORM. Vous travaillez avec Prisma ou Drizzle, le client tourne sous MSSQL, votre dev local est PostgreSQL. Il vous faut deux versions du script d'init.
Construction de tables BigQuery depuis une base opérationnelle. Le schéma MySQL doit être adapté à BigQuery, qui n'a pas d'AUTO_INCREMENT et présente de nombreuses différences de types.
Revue de code d'une requête venant d'un collègue qui écrit pour un autre moteur. Vérification rapide qu'elle tournera sur votre base.
Apprendre les différences entre dialectes. Collez une requête simple, changez le dialecte cible, observez ce qui change. Mieux que de lire une doc aride.
Vérification de portabilité d'un schéma existant. La conversion met en évidence les endroits où vous utilisez des constructions spécifiques à un éditeur.

Après conversion, formatez la sortie avec notre formateur SQL. Vous voulez un schéma ORM à la place ? Voir le convertisseur SQL vers ORM.

Questions et réponses

Convertisseur dialectes SQL

Pourquoi un convertisseur de dialectes SQL ?

Mode d'emploi

Quand c'est utile

Questions et réponses

Outils similaires

Formateur SQL

SQL vers ORM

DBML vers SQL

Parseur connection string DB

Convertisseur dialectes SQL

Pourquoi un convertisseur de dialectes SQL ?

Mode d'emploi

Quand c'est utile

Questions et réponses

Outils similaires

Formateur SQL

SQL vers ORM

DBML vers SQL

Parseur connection string DB