¿Por qué un conversor de dialectos SQL?
Cada base de datos tiene su propio sabor de SQL. PostgreSQL usa `SERIAL` para una clave autoincremental, MySQL usa `AUTO_INCREMENT`, MSSQL usa `IDENTITY(1,1)`, Oracle usa `GENERATED AS IDENTITY`. El SQL estándar es teórico, en la práctica cada proveedor le pegó sus propias extensiones.
Pegas una query de una base de datos, eliges el dialecto origen y destino, y la herramienta reescribe las partes que difieren: tipos de columna (TINYINT vs BOOLEAN vs BIT vs NUMBER(1)), claves autoincrementales, paginación (`LIMIT/OFFSET` vs `TOP` vs `FETCH NEXT`), funciones de tiempo (`NOW()` vs `GETDATE()` vs `SYSDATE`), concatenación de strings (`||` vs `CONCAT()`), entrecomillado de identificadores (`` `id` `` vs `[id]` vs `"id"`).
A la derecha ves la lista de cambios aplicados con una breve razón. Sin magia, solo un ruleset decente que cubre alrededor del 80% del porting de schemas simples.
Cómo usarla
- Elige el dialecto origen (de dónde viene la query) y el dialecto destino (donde quieres ejecutarla).
- Pega tu SQL en el panel izquierdo. Puede ser `CREATE TABLE`, `SELECT`, `INSERT`, lo que sea.
- A la derecha obtienes el resultado convertido, formateado automáticamente para el dialecto destino.
- Debajo ves la lista de cambios hechos: cada regla con un diff "antes / después" y una etiqueta breve.
- Copia el resultado con el botón Copiar. Luego revisa la lógica (las regex no pueden con todo, a veces hacen falta ajustes manuales).
- Usa las flechas swap para invertir origen y destino. Útil cuando quieres convertir en ambas direcciones.
Cuándo es útil
Escenarios comunes:
- Migrar de MySQL a PostgreSQL. El clásico: la empresa creció, MySQL no basta, te pasas a Postgres. El schema necesita reescritura. Esta herramienta gestiona el 80% del trabajo gris.
- Soportar dos bases de datos en un ORM. Trabajas con Prisma o Drizzle, el cliente corre MSSQL, tu dev local es PostgreSQL. Necesitas dos versiones del script de init.
- Construir tablas BigQuery desde una base de datos operacional. El schema MySQL necesita adaptarse a BigQuery, que no tiene AUTO_INCREMENT y muchas diferencias de tipo.
- Revisión de código de una query de un compañero que escribe contra otro engine. Comprobación rápida de cordura sobre si correrá en tu base de datos.
- Aprender diferencias entre dialectos. Pega una query simple, cambia el dialecto destino, mira qué cambia. Mejor que leer documentación seca.
- Comprobación de portabilidad de un schema existente. La conversión resalta dónde usas construcciones específicas de vendor.
Tras convertir, formatea la salida con nuestro formateador SQL. ¿Quieres un schema ORM en su lugar? Mira el conversor SQL a ORM.