Migração de MySQL para Postgres — quando vale a pena, as pegadinhas e o workflow do pgloader

Já migramos bancos de dados nos dois sentidos: MySQL → Postgres para times que precisam de índices ricos, semântica ACID real em DDL e a história do JSONB; Postgres → MySQL para times que acharam o modelo de conexões do Postgres caro demais para a carga deles. A migração é uma peça real de engenharia em qualquer sentido, e os motivos errados para fazê-la («a gente gosta mais») vão queimar meses.

Este é o framework de decisão, as armadilhas de tipos de dados, e o workflow do pgloader que usamos quando MySQL → Postgres é a escolha certa.

O ponto de entrada do 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 lida com 80 % da tradução de tipos automaticamente. Os 20 % restantes são onde a engenharia acontece.

O artigo completo cobre:

• Quando a migração é a resposta certa (e os três motivos ruins comuns)
• As armadilhas de tipos de dados: zero dates, tinyint(1) vs boolean, BLOB vs bytea, tratamento de charset
• Reset de sequences após carga de dados
• Mudanças no nível da aplicação (case-sensitivity, performance de LIMIT/OFFSET, RETURNING em vez de SELECT LAST_INSERT_ID)
• O padrão de cutover dual-write para bancos em produção
• Verificar row counts e checksums entre origem e destino

Fale conosco se está pesando essa migração para uma carga real.