Convivir con PostgreSQL y Azure SQL durante una migración
Migrar entre Azure SQL y PostgreSQL —o mantener ambos sistemas durante una transición prolongada— rara vez es un volcado único. Suele ser convivencia temporal: dos motores, dos equipos de herramientas, una verdad de negocio que aún no ha elegido residencia definitiva. Este artículo describe estrategias para ese periodo sin afirmar que existe una receta universal.
Por qué convivir en lugar de cortar
Un big-bang cutover concentra riesgo en una ventana corta. Convivir permite:
- validar equivalencia con tráfico real o sombra;
- migrar dominios por fases;
- mantener rollback mientras el destino madura.
El coste es complejidad operativa: sincronización, divergencia, gobernanza de esquemas duplicados.
Estrategias de sincronización
| Estrategia | Cuándo encaja |
|---|---|
| Batch | Volúmenes acotados, ventanas nocturnas, tolerancia a lag. |
| Sincronización controlada | Jobs idempotentes con checkpoints y reconciliación. |
| Transactional Outbox | Eventos de negocio con atomicidad local; ver Transactional Outbox. |
| CDC | Cambios continuos desde WAL/binlog; latencia baja. |
| Rehearsals de migración | Ensayos completos sin cutover; ver Rehearsal Pattern. |
Ninguna estrategia elimina la necesidad de reconciliación: comparar conteos, checksums o muestras estratificadas entre origen y destino.
CDC y Debezium como alternativa, no como afirmación
Change Data Capture puede replicar cambios en near-real-time desde PostgreSQL hacia downstream —incluido un destino Azure SQL o un pipeline intermedio. Debezium es una implementación conocida de CDC sobre Kafka Connect.
No afirmo que este proyecto utilice Debezium actualmente. Aparece aquí como referencia arquitectónica y posibilidad futura, no como componente desplegado en el archivo. Elegir CDC implica operar conectores, schemas de eventos, lag y compensaciones —decisión distinta a batch nocturno.
OLTP, no transformación analítica central
Este artículo habla de evolución e integración OLTP: pedidos, clientes, pagos en movimiento. No posiciona dbt ni capas analíticas como pieza central del puente. Las cargas analíticas pueden consumir réplicas o eventos derivados, pero la migración del sistema transaccional tiene otras restricciones —latencia, FK, transacciones cortas.
Puente con modernización legacy
La modernización incremental comparte el espíritu de este artículo: el origen sigue vivo mientras una capa limpia crece alrededor. Durante una migración entre ambos motores, esa capa puede ser API + mapping que abstrae el motor concreto mientras conviven ambos.
Rehearsals antes del cutover
Un rehearsal de migración ejecuta el plan completo —export, transform, load, smoke— contra un entorno desechable. Detecta incompatibilidades de tipos, collations, secuencias y stored procedures antes de tocar producción.
Confundir rehearsal con cutover es error clásico: el ensayo debe ser reversible y observable, con criterios de éxito definidos antes de empezar.
Límites
Convivencia prolongada puede cristalizarse en deuda si no hay fecha de fin. Dos fuentes de verdad exigen gobernanza explícita: ¿quién gana en conflicto? ¿cómo se depreca el origen?
Este artículo no documenta herramientas concretas desplegadas ni cronogramas reales. Ofrece vocabulario para decidir estrategias cuando PostgreSQL y Azure SQL deben coexistir con rigor, no con optimismo.