Migración de MySQL a Postgres — cuándo merece la pena, los baches y el workflow de pgloader

Hemos migrado bases de datos en ambos sentidos: MySQL → Postgres para equipos que necesitan índices ricos, semántica ACID real en DDL y la historia de JSONB; Postgres → MySQL para equipos que encontraron el modelo de conexiones de Postgres demasiado caro para su carga. La migración es una pieza real de ingeniería en cualquier sentido, y las razones equivocadas para hacerla («nos gusta más») quemarán meses.

Este es el marco de decisión, las trampas de tipos de datos, y el workflow de pgloader que usamos cuando MySQL → Postgres es la llamada correcta.

El punto de entrada de pgloader

LOAD DATABASE
  FROM mysql://user:pass@source/dbname
  INTO postgresql://user:pass@dest/dbname
 
WITH include drop, create tables, create indexes, reset sequences,
     workers = 8, concurrency = 1,
     multiple readers per thread, rows per range = 50000
 
CAST type datetime to timestamptz drop default drop not null using zero-dates-to-null,
     type tinyint when (= precision 1) to boolean using tinyint-to-boolean
;

pgloader maneja el 80 % de la traducción de tipos automáticamente. El 20 % restante es donde sucede la ingeniería.

El artículo completo cubre:

• Cuándo la migración es la respuesta correcta (y las tres razones malas comunes)
• Las trampas de tipos de datos: zero dates, tinyint(1) vs boolean, BLOB vs bytea, manejo de juegos de caracteres
• Reset de secuencias tras la carga de datos
• Cambios a nivel de aplicación (sensibilidad a mayúsculas, rendimiento de LIMIT/OFFSET, RETURNING en vez de SELECT LAST_INSERT_ID)
• El patrón de cutover dual-write para bases vivas
• Verificar row counts y checksums entre origen y destino

Háblanos si estás sopesando esta migración para una carga real.