MySQL y PostgreSQL utilizan SQL, pero no siempre lo interpretan de la misma manera.
Una consulta puede parecer perfectamente normal en MySQL y aun así fallar o comportarse de forma diferente después de trasladarla a PostgreSQL.
Estas son siete diferencias que conviene comprobar durante una migración.
1. Comillas para identificadores
MySQL suele utilizar comillas invertidas alrededor de los nombres de tablas y columnas:
SELECT `name`, `order`
FROM `customers`;
PostgreSQL utiliza comillas dobles para los identificadores entrecomillados:
SELECT "name", "order"
FROM "customers";
El uso de comillas se vuelve especialmente importante cuando un identificador contiene espacios, letras mayúsculas o palabras reservadas.
Un mejor enfoque a largo plazo consiste en utilizar, siempre que sea posible, identificadores sencillos en minúsculas que no requieran comillas.
2. ID generados automáticamente
Una tabla de MySQL puede utilizar AUTO_INCREMENT:
CREATE TABLE customers (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(100)
);
Un equivalente moderno en PostgreSQL puede utilizar una columna de identidad:
CREATE TABLE customers (
id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
name VARCHAR(100)
);
PostgreSQL también admite SERIAL, pero las columnas de identidad ofrecen un comportamiento más claro y basado en estándares para los esquemas nuevos.
Después de migrar los datos, verifica que la secuencia de PostgreSQL continúe después del ID importado más alto.
3. Valores booleanos
Las aplicaciones MySQL suelen representar los valores booleanos con TINYINT:
CREATE TABLE users (
is_active TINYINT(1)
);
PostgreSQL tiene un tipo BOOLEAN específico:
CREATE TABLE users (
is_active BOOLEAN
);
Es posible que valores como 1 y 0 deban convertirse en TRUE y FALSE.
Esta diferencia también puede afectar al código de la aplicación, los filtros, los valores predeterminados y los datos importados.
4. Gestión de valores NULL
MySQL proporciona IFNULL:
SELECT IFNULL(phone_number, 'Not provided')
FROM customers;
PostgreSQL suele utilizar COALESCE:
SELECT COALESCE(phone_number, 'Not provided')
FROM customers;
Ambas bases de datos admiten COALESCE, lo que puede facilitar futuras migraciones.
Aun así, el comportamiento de NULL debe probarse cuidadosamente en comparaciones, concatenaciones, cálculos y expresiones condicionales.
5. Operaciones aritméticas con fechas
MySQL puede añadir siete días con DATE_ADD:
SELECT DATE_ADD(order_date, INTERVAL 7 DAY)
FROM orders;
PostgreSQL puede expresar la misma operación con un intervalo:
SELECT order_date + INTERVAL '7 days'
FROM orders;
La sintaxis visible es solo una parte de la diferencia.
Comprueba también los tipos de fecha, las marcas de tiempo, las zonas horarias, los límites de los meses y el comportamiento del horario de verano cuando sean relevantes para la aplicación.
6. Concatenación de cadenas
MySQL suele utilizar CONCAT:
SELECT CONCAT(first_name, ' ', last_name)
FROM customers;
PostgreSQL admite CONCAT, pero también utiliza habitualmente el operador de doble barra vertical:
SELECT first_name || ' ' || last_name
FROM customers;
Ten cuidado cuando los valores puedan ser NULL. Los distintos métodos de concatenación pueden producir resultados diferentes según las entradas.
Prueba los nombres, las direcciones, las etiquetas de informes y otras expresiones que combinen varias columnas.
7. Sintaxis de upsert
MySQL puede insertar o actualizar una fila con ON DUPLICATE KEY UPDATE:
INSERT INTO products (id, name, price)
VALUES (10, 'Keyboard', 49.99)
ON DUPLICATE KEY UPDATE
name = VALUES(name),
price = VALUES(price);
PostgreSQL utiliza ON CONFLICT:
INSERT INTO products (id, name, price)
VALUES (10, 'Keyboard', 49.99)
ON CONFLICT (id) DO UPDATE SET
name = EXCLUDED.name,
price = EXCLUDED.price;
La instrucción de PostgreSQL identifica explícitamente el objetivo del conflicto.
Revisa las restricciones y los índices únicos antes de convertir los upserts, ya que determinan qué conflictos puede detectar PostgreSQL.
¿Qué más debe probarse?
La conversión de la sintaxis es solo el primer paso.
Después de convertir una consulta o un esquema de MySQL, compara el comportamiento de origen y destino utilizando datos representativos.
Comprueba:
• Cantidad de filas
• Valores NULL
• ID generados
• Resultados de fecha y hora
• Precisión decimal
• Distinción entre mayúsculas y minúsculas
• Orden de clasificación
• Gestión de duplicados
• Valores predeterminados
Que el SQL se ejecute correctamente no significa automáticamente que se comporte de forma correcta.
Un flujo de trabajo de migración fiable
Un flujo de trabajo práctico de MySQL a PostgreSQL es:
Comprender el SQL de origen
Convertirlo a PostgreSQL
Revisar los cambios específicos del dialecto
Inspeccionar los diagnósticos
Probar con datos representativos
Comparar los resultados
Implementar solo después de la validación
Sqlinfy puede ayudar a crear una primera conversión estructurada entre MySQL y PostgreSQL. Aun así, los desarrolladores deben revisar y probar el SQL convertido antes de utilizarlo en producción.
