6 respuestas

★ Mejor respuesta

¿Tu aplicación puede estar un rato sin escribir a la BD o necesitás cero downtime absoluto? Si podés parar las escrituras aunque sea 5-10 minutos, pg_upgrade es tu mejor amiga porque convierte los archivos en el mismo disco sin exportar nada, así que con 50GB te ahorrás horas.

Ahora, si necesitás evitar downtime por completo, hay un truco que pocas veces mencionan: podés usar replicación lógica (logical replication) para sincronizar la BD vieja con la nueva en paralelo mientras sigue corriendo, y luego switcheás cuando esté todo al día - es un poco más complicado de configurar pero es gold si no podés parar el servicio.

Eso sí, antes de cualquier cosa testealo en un ambiente de staging aunque sea con un dump de algunos GB para ver cuánto tarda en tu setup específico.

DiegoHernandez asker Podemos parar escrituras 10 minutos tranquilamente. Voy a probar pg_upgrade entonces, gracias por el dato.

No hagas un pg_dump simple y restore en una base de datos vacía si no quieres estar con downtime de horas - en su lugar usa pg_upgrade que corre en el mismo servidor sin necesidad de exportar/importar, o si querés migrar a otro servidor usa replicación lógica para mantener la app corriendo mientras se sincroniza. Con 50GB vas a ahorrar un montón de tiempo y estrés haciéndolo de esa forma.

¿Ya verificaste que tu versión 12 es compatible directamente con la 15, o necesitás pasar por versiones intermedias?

Lo que nadie menciona es que además de pg_upgrade, deberías considerar hacer un backup completo antes de cualquier cosa, porque aunque pg_upgrade es bastante confiable, tener ese respaldo te da paz mental - especialmente con 50GB.

Si sí o sí necesitás evitar downtime total, existe replicación lógica (logical replication) donde configurás una instancia secundaria con la versión 15, la sincronizás en paralelo y luego hacés failover cuando esté lista, pero eso es más complejo. La mayoría de la gente que conozco termina eligiendo pg_upgrade con una ventana de mantenimiento corta porque es lo más práctico y rápido para un volumen así.

LU Luis ES 🔍 Entusiasta 💬 55 respuestas

Con 50GB tienes que ser cuidadoso pero pg_upgrade sí es la opción correcta si puedes tolerar ese downtime de 5-10 minutos.

Lo que la mayoría no menciona es que PostgreSQL 12 a 15 es un salto que pg_upgrade maneja sin problemas en una única pasada, así que no necesitas versiones intermedias. Mi consejo: antes de cualquier cosa, haz un backup completo con pg_basebackup o pg_dump en paralelo (usa pg_dump con la opción -j para paralelizar, reduce bastante el tiempo), y luego sí ejecuta pg_upgrade en tu servidor de producción durante una ventana de mantenimiento.

Eso sí, después del upgrade corre ANALYZE en las tablas grandes porque cambian algunas estadísticas internas y podrías tener queries lentas si no lo haces.

Si podés tolerar aunque sea 10-15 minutos de downtime, pg_upgrade es definitivamente tu camino porque hace la migración en el mismo servidor sin exportar/importar toda la data (con 50GB eso te ahorra un montón de tiempo).

Lo que nadie mencionó acá es que antes de cualquier cosa, tenés que revisar si hay extensiones instaladas que no sean compatibles entre versiones, porque eso puede frenar todo el proceso a último momento y dejarte con sorpresas desagradables cuando ya estés en la conversión.

Mi recomendación: hacé un backup full con pg_basebackup igual (por si acaso), testea todo en un servidor de staging primero, y después sí lanzate con pg_upgrade en producción.

Sergio MX 🔍 Entusiasta 💬 41 respuestas

PostgreSQL 12 a 15 funciona directo sin pasar por versiones intermedias, así que pg_upgrade es tu camino. Lo que sí importa acá es que antes de correr pg_upgrade, necesitás hacer un backup completo con pg_dump o un backup físico - no para la migración en sí, sino como red de seguridad. Mucha gente salta este paso porque confia en que pg_upgrade va a funcionar, pero si algo sale mal con 50GB de datos, no querés estar rezando.

El proceso es bastante directo: instalás PostgreSQL 15 en el mismo servidor (o en uno paralelo si preferís), pausás las escrituras a la BD, corrés pg_upgrade con la flag `-k` para mantener los archivos viejos como respaldo, y déjalo correr. Con 50GB talvez tarde 5-15 minutos dependiendo del hardware, pero después tenés todo convertido in-place sin exportar/importar nada. Una vez que confirmas que anda todo bien, recién ahí borras los archivos viejos de la versión 12.

Lo importante que no ves mencionado es verificar los extension y configuraciones custom. Si tenes extensiones instaladas, pg_upgrade puede tener problemas - necesitás que existan en PostgreSQL 15 también. Antes de hacer cualquier cosa, chequea `SELECT extname FROM pg_extension;` en tu BD actual y confirmá que todas esas extensiones soporten la versión 15. Eso es donde más suele fallar la cosa, no en la migración de datos en sí.

Tu respuesta

Iniciar sesiónpara responder.