La señal del 24 de septiembre: beta 4 y funcionalidades eliminadas
La beta 4 de PostgreSQL 19 se publicó el 24 de septiembre de 2026 en postgresql.org/about/news/. El ciclo habitual de lanzamiento de PostgreSQL contempla 3 o 4 betas antes de la disponibilidad general en octubre; una cuarta beta en septiembre indica que el proyecto no ha alcanzado el nivel de estabilidad objetivo en el plazo previsto.
La novedad destacada de esta beta no es una corrección técnica — es la lista de eliminaciones. El análisis publicado por el equipo de ingeniería de Snowflake contabiliza 53 funcionalidades planificadas originalmente para PostgreSQL 19 que han sido aplazadas a una versión posterior. Este tipo de aplazamiento masivo en fase beta es poco frecuente en la historia del proyecto, que ha mantenido durante veinte años una cadencia anual muy regular.
Consecuencia directa: la GA de PostgreSQL 19 se espera ahora para finales de octubre de 2026, con varias semanas de retraso respecto al calendario inicial. Para un stack autoalojado en producción, este desplazamiento no es trivial: comprime la ventana de pruebas antes del congelamiento de fin de año y retrasa todo el calendario de migración.
Qué se ha eliminado y por qué importa
Entre las 53 funcionalidades eliminadas, tres grupos merecen la atención de los desarrolladores que trabajan con stacks de aplicaciones modernas.
Eliminaciones que afectan a los desarrolladores de aplicaciones
- SQL/JSON path improvements — mejoras a la navegación
jsonpathen documentos JSON anidados, muy utilizadas en APIs REST que almacenan datos semiestructurados. Su eliminación significa que las consultas que dependían de ellas deberán continuar usando alternativas más verbosas. - SQL graph queries (ISO SQL:2016) — soporte de consultas de grafos según el estándar ISO SQL:2016, que habría permitido modelar relaciones complejas directamente en SQL estándar sin extensiones. Esta eliminación es relevante para proyectos que querían migrar de soluciones NoSQL a PostgreSQL.
- MERGE improvements backportados a PG 18 — las mejoras de la cláusula
MERGEplanificadas para PG 19 han sido aplazadas. Parte de ellas han sido backporteadas a PostgreSQL 18, lo que refuerza retroactivamente el atractivo de esa versión.
Por qué estas eliminaciones no invalidan PG 19
Eliminar una funcionalidad en beta es una señal de madurez, no de fracaso. El proyecto PostgreSQL prefiere entregar menos que entregar inestable — esto es lo que le otorga su reputación de fiabilidad en producción. Las 53 funcionalidades eliminadas serán candidatas para PostgreSQL 20. Lo que debe captar tu atención es el calendario: la ventana de pruebas antes de la GA es ahora muy corta.
Impacto concreto por stack autoalojado
La pregunta práctica no es «¿es bueno PostgreSQL 19?» sino «¿en qué versión corre mi stack, y cambia PG 19 algo en mi plan de migración?». Las cuatro herramientas más comunes en VPS autoalojados tienen requisitos documentados que orientan la respuesta.
n8n documenta PostgreSQL 14+ como base de datos soportada. En producción autoalojada, las instancias n8n corren mayoritariamente en PG 14 o PG 15 — una migración a PG 18 es un salto controlado, sin funcionalidades de PG 19 requeridas por la aplicación.
Supabase distribuye PostgreSQL 15 por defecto en su imagen autoalojada. El proyecto sigue las versiones estables con un retraso de calificación interna de algunas semanas. PG 19 no será soportado hasta varios meses después de la GA; apuntar a PG 18 para una instancia Supabase autoalojada es la trayectoria coherente.
Nextcloud 35 indica PostgreSQL 15+ en su documentación oficial. Ninguna funcionalidad de PG 19 es requerida por Nextcloud actualmente.
Mattermost Team Edition documenta PostgreSQL 14+ como requisito. Migrar a PG 18 no requiere cambios en la aplicación — el esquema es compatible.
Versión de PostgreSQL requerida por aplicación autoalojada
Desplace la tabla
| Aplicación | Versión PG mínima documentada | Versión PG distribuida por defecto | Compatible con PG 18 | Requiere PG 19 |
|---|---|---|---|---|
| n8n | PG 14+ | PG 14 o 15 según imagen | Sí (sin cambios requeridos) | No |
| Supabase self-hosted | PG 15+ | PG 15 (imagen oficial) | Sí (calificación en curso) | No |
| Nextcloud 35 | PG 15+ | PG 15 recomendado | Sí | No |
| Mattermost Team Edition | PG 14+ | PG 14 o 15 | Sí | No |
La recomendación: PostgreSQL 18 es el objetivo intermedio sano
PostgreSQL 18 alcanzó la disponibilidad general en abril de 2026. Cuenta con un ciclo de soporte de cinco años (hasta 2031) y lleva varios meses estable en producción. Esta es la versión que los equipos que planificaban PG 19 deberían apuntar ahora.
Tres razones concretas favorecen PG 18 como objetivo intermedio:
1. Las MERGE improvements previstas para PG 19 han sido parcialmente backporteadas a PG 18 — te beneficias de ellas sin esperar.
2. La migración PG 17 → PG 18 está documentada y sin fricciones importantes. La compatibilidad de extensiones comunes (pgvector, PostGIS, TimescaleDB) está asegurada.
3. Cinco años de soporte desde abril de 2026 — sin presión inmediata de actualización, y una ventana cómoda para calificar PG 19 cuando sea realmente estable en producción.
La estrategia correcta: migrar a PG 18 ahora, planificar PG 19 para 2027.
Guía de migración PG 16/17 → PG 18
La migración mayor de PostgreSQL se realiza con pg_upgrade, la herramienta estándar del proyecto. Requiere una parada del servicio pero no una reinstalación completa — el catálogo y los datos se conservan.
Pasos para migrar PG 16 o PG 17 a PG 18
Respaldar la base de datos antes de cualquier operación
Una migración mayor es irreversible sin respaldo. Realiza un volcado completo:
pg_dumpall -U postgres > /backup/pg_full_$(date +%Y%m%d).sqlVerifica que el archivo sea legible y no esté vacío antes de continuar. En un VPS, copia también el volcado a un almacenamiento externo.
Instalar PostgreSQL 18 junto a la versión existente
En Debian/Ubuntu, el repositorio PGDG permite instalar múltiples versiones en paralelo:
apt install postgresql-18Ambas instancias coexisten en puertos diferentes.
pg_upgraderealizará la migración entre los dos clústeres sin iniciar la instancia antigua.Detener la instancia antigua y ejecutar pg_upgrade
Detén limpiamente la instancia antigua (PG 16 o PG 17):
systemctl stop postgresql@17-mainEjecuta
pg_upgradeen modo verificación (--check) primero:pg_upgrade \ -b /usr/lib/postgresql/17/bin \ -B /usr/lib/postgresql/18/bin \ -d /var/lib/postgresql/17/main \ -D /var/lib/postgresql/18/main \ --checkSi la verificación pasa sin errores, ejecuta de nuevo sin
--checkpara realizar la migración.Reconfigurar el puerto y reiniciar
Tras la migración, apunta tu aplicación al clúster PG 18. Si conservas el puerto 5432, edita
/etc/postgresql/18/main/postgresql.conf:port = 5432Inicia la instancia PG 18:
systemctl start postgresql@18-mainVerifica la versión activa:
psql -U postgres -c "SELECT version();"Analizar y limpiar tras la migración
Tras
pg_upgrade, reconstruye las estadísticas en todas las bases de datos:vacuumdb --all --analyze-in-stages -U postgresUna vez validado, puedes eliminar el clúster antiguo y sus paquetes:
/usr/lib/postgresql/17/bin/pg_dropcluster 17 main apt remove postgresql-17
Verificar la versión de PostgreSQL en producción
Antes de planificar cualquier cosa, conocer la versión exacta en producción es indispensable. Los comandos varían según el contexto de instalación.
Comandos de diagnóstico de versión
- Vía psql:
psql -U postgres -c "SELECT version();"— muestra la versión completa incluyendo el número de parche. - Vía systemctl:
systemctl status postgresql— indica el nombre del servicio activo, que contiene el número de versión principal. - Vía Docker:
docker exec <container> psql -U postgres -c "SELECT version();"para una instancia en contenedor. - Vía pg_lsclusters (Debian/Ubuntu):
pg_lsclusters— lista todos los clústeres instalados, sus puertos, estado y versión. - Vía los logs de la aplicación: n8n, Supabase y Mattermost registran la versión de PostgreSQL al arrancar — revisa los logs si no tienes acceso directo al servidor.
Planificar la migración a PG 19: cronograma y precauciones
La GA de PostgreSQL 19 se espera para finales de octubre de 2026. El cronograma realista para la adopción en producción autoalojada es el siguiente:
- Finales de octubre 2026: GA de PG 19, primeros paquetes PGDG disponibles.
- Noviembre–diciembre 2026: período a evitar para migraciones en producción — congelamiento de fin de año, equipos con menos personal, alto riesgo operativo.
- Enero–febrero 2027: primer parche de mantenimiento de PG 19. Esta es la señal estándar para considerar pruebas en staging.
- T1–T2 2027: calificación en una instancia de staging con un volcado de producción anonimizado, validación de extensiones, pruebas de rendimiento.
- T2–T3 2027: migración a producción para los equipos que hayan completado el ciclo completo de validación.
Tres precauciones que nunca hay que saltarse:
1. Prueba primero en un volcado de producción anonimizado, no en datos de prueba sintéticos — los volúmenes y patrones de consulta reales revelan regresiones que los fixtures no ven.
2. Verifica la compatibilidad de cada extensión antes de migrar: pgvector, PostGIS, pg_cron, pg_trgm tienen cada una su propio ciclo de calificación para cada versión mayor.
3. Mantén un plan de rollback documentado: con pg_upgrade, volver atrás es posible mientras no hayas eliminado el clúster antiguo — documenta el procedimiento de restauración antes de migrar.
Preparar tu VPS para PG 18 con Docker
Si tu stack ya corre en Docker, la migración a PG 18 puede hacerse en paralelo a la instancia de producción, sin pg_upgrade. La imagen oficial postgres:18 está disponible en Docker Hub desde la GA de abril de 2026.
Desplegar PG 18 en un VPS con Docker Compose
Crear el archivo docker-compose.yml para PG 18
Crea un directorio dedicado y el archivo de configuración:
mkdir -p /opt/postgres18 && cd /opt/postgres18Contenido del
docker-compose.yml:cat > docker-compose.yml << 'EOF' services: postgres: image: postgres:18 container_name: postgres18 restart: unless-stopped environment: POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} POSTGRES_USER: ${POSTGRES_USER:-postgres} POSTGRES_DB: ${POSTGRES_DB:-app} volumes: - ./data:/var/lib/postgresql/data ports: - "127.0.0.1:5432:5432" EOFCrea un archivo
.envcon tus valores:echo 'POSTGRES_PASSWORD=contraseña_segura_aquí' > .envImportar los datos desde la instancia antigua
Inicia el nuevo contenedor:
docker compose up -dRestaura el volcado desde tu instancia antigua (PG 16 o PG 17):
psql -U postgres -h 127.0.0.1 -p 5432 < /backup/pg_full_$(date +%Y%m%d).sqlVerifica que las bases de datos y tablas estén presentes:
docker exec postgres18 psql -U postgres -lVerificar y cambiar la aplicación
Antes de cambiar la aplicación, verifica la versión activa en el contenedor:
docker exec postgres18 psql -U postgres -c "SELECT version();"Actualiza la variable
DATABASE_URL(oDB_HOST/DB_PORT) de tu aplicación para apuntar al nuevo contenedor. Reinicia la aplicación y revisa los logs de inicio — n8n, Nextcloud y Mattermost registran todos la conexión PostgreSQL al inicializarse.
Un VPS con acceso root te da el margen que el hosting gestionado no tiene
Probar PG 18 junto a tu instancia de producción, validar tu stack en un volcado anonimizado y revertir sin depender de un proveedor: eso es lo que posibilita el acceso root en un VPS. El hosting compartido o un PaaS gestionado impone el calendario de actualizaciones del proveedor — a menudo sin aviso previo sobre la versión objetivo ni posibilidad de pruebas previas.
Conclusión: actúa ahora, no después de la GA de PG 19
El retraso de PostgreSQL 19 y la eliminación de 53 funcionalidades no son señales de alarma sobre la calidad del proyecto — es el proceso normal de publicación de un software de este alcance. Pero cambian el calendario de los equipos que planeaban un salto directo a PG 19 antes de finales de 2026.
La ventana de acción es ahora, antes de la GA de PG 19:
- Si estás en PG 15 o PG 16: planifica la migración a PG 18. Es la versión estable, con 5 años de soporte, cuyas funcionalidades cubren todos los requisitos de los stacks autoalojados comunes.
- Si estás en PG 17: estás en buena posición. PG 17 sigue soportado hasta 2029; la migración a PG 18 puede esperar un ciclo de mantenimiento tranquilo.
- En todos los casos: no planifiques PG 19 en producción antes del T2 2027 — la calificación de extensiones y los primeros resultados de producción requieren varios meses tras la GA.
El calendario de migración se decide cuando las opciones están abiertas, no cuando la presión operativa cierra las puertas.
