[{"data":1,"prerenderedAt":236},["ShallowReactive",2],{"seo-verification":3,"blog-postgresql-19-retrasado-impacto-en-apps-self-hosted-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-postgresql-19-retrasado-impacto-en-apps-self-hosted-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":144,"ctaBody":145,"ctaButton":146,"ctaUrl":147,"relatedPosts":148},378,"postgresql-19-retrasado-impacto-en-apps-self-hosted",{"fr":12,"en":13,"ar":14,"es":10},"postgresql-19-retard-impact-apps-self-hosted","postgresql-19-delayed-impact-on-self-hosted-apps","تأخير-postgresql-19-وتأثيره-على-التطبيقات-المستضافة","PostgreSQL 19 retrasado: impacto en apps self-hosted","PostgreSQL 19 beta 4 elimina 53 funcionalidades y retrasa la GA a fin de octubre 2026. Impacto en n8n, Supabase, Nextcloud, Mattermost — y por qué PG 18 es el objetivo.",11,0,false,"2026-09-25T00:00:00+00:00","2026-09-25T23:43:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},6,"Bases de datos","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fpostgresql-19-retard-impact-apps-self-hosted-poster.svg","El 24 de septiembre de 2026, el proyecto PostgreSQL publicó la beta 4 de PostgreSQL 19 con una lista inesperada: 53 funcionalidades eliminadas del alcance del lanzamiento y una fecha de disponibilidad general postergada a finales de octubre de 2026. Para los equipos que planeaban el salto PG 17 → PG 19 antes de fin de año, esta señal cambia los cálculos. Este artículo detalla qué se ha eliminado, por qué importa para los stacks autoalojados y cuál es el objetivo de migración más razonable hoy.",[35,39,42,49,53,56,84,87,90,109,112,120,123,126,138,141],{"type":36,"title":37,"body":38},"h2","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 \u003Ca href=\"https:\u002F\u002Fwww.postgresql.org\u002Fabout\u002Fnews\u002F\">postgresql.org\u002Fabout\u002Fnews\u002F\u003C\u002Fa>. 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.\n\nLa 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.\n\nConsecuencia 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.",{"type":36,"title":40,"body":41},"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.",{"type":43,"title":44,"items":45},"ul","Eliminaciones que afectan a los desarrolladores de aplicaciones",[46,47,48],"**SQL\u002FJSON path improvements** — mejoras a la navegación `jsonpath` en 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 `MERGE` planificadas 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.",{"type":50,"title":51,"body":52},"tip","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.",{"type":36,"title":54,"body":55},"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.\n\n**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.\n\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.\n\n**Nextcloud 35** indica PostgreSQL 15+ en su documentación oficial. Ninguna funcionalidad de PG 19 es requerida por Nextcloud actualmente.\n\n**Mattermost Team Edition** documenta PostgreSQL 14+ como requisito. Migrar a PG 18 no requiere cambios en la aplicación — el esquema es compatible.",{"type":57,"title":58,"headers":59,"rows":65},"comparison","Versión de PostgreSQL requerida por aplicación autoalojada",[60,61,62,63,64],"Aplicación","Versión PG mínima documentada","Versión PG distribuida por defecto","Compatible con PG 18","Requiere PG 19",[66,72,77,81],[67,68,69,70,71],"n8n","PG 14+","PG 14 o 15 según imagen","Sí (sin cambios requeridos)","No",[73,74,75,76,71],"Supabase self-hosted","PG 15+","PG 15 (imagen oficial)","Sí (calificación en curso)",[78,74,79,80,71],"Nextcloud 35","PG 15 recomendado","Sí",[82,68,83,80,71],"Mattermost Team Edition","PG 14 o 15",{"type":36,"title":85,"body":86},"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.\n\nTres razones concretas favorecen PG 18 como objetivo intermedio:\n\n1. **Las MERGE improvements** previstas para PG 19 han sido parcialmente backporteadas a PG 18 — te beneficias de ellas sin esperar.\n2. **La migración PG 17 → PG 18** está documentada y sin fricciones importantes. La compatibilidad de extensiones comunes (pgvector, PostGIS, TimescaleDB) está asegurada.\n3. **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.\n\nLa estrategia correcta: migrar a PG 18 ahora, planificar PG 19 para 2027.",{"type":36,"title":88,"body":89},"Guía de migración PG 16\u002F17 → 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.",{"type":91,"title":92,"steps":93},"steps","Pasos para migrar PG 16 o PG 17 a PG 18",[94,97,100,103,106],{"title":95,"body":96},"Respaldar la base de datos antes de cualquier operación","Una migración mayor es irreversible sin respaldo. Realiza un volcado completo:\n\n```bash\npg_dumpall -U postgres > \u002Fbackup\u002Fpg_full_$(date +%Y%m%d).sql\n```\n\nVerifica 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.",{"title":98,"body":99},"Instalar PostgreSQL 18 junto a la versión existente","En Debian\u002FUbuntu, el repositorio PGDG permite instalar múltiples versiones en paralelo:\n\n```bash\napt install postgresql-18\n```\n\nAmbas instancias coexisten en puertos diferentes. `pg_upgrade` realizará la migración entre los dos clústeres sin iniciar la instancia antigua.",{"title":101,"body":102},"Detener la instancia antigua y ejecutar pg_upgrade","Detén limpiamente la instancia antigua (PG 16 o PG 17):\n\n```bash\nsystemctl stop postgresql@17-main\n```\n\nEjecuta `pg_upgrade` en modo verificación (`--check`) primero:\n\n```bash\npg_upgrade \\\n  -b \u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin \\\n  -B \u002Fusr\u002Flib\u002Fpostgresql\u002F18\u002Fbin \\\n  -d \u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fmain \\\n  -D \u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fmain \\\n  --check\n```\n\nSi la verificación pasa sin errores, ejecuta de nuevo sin `--check` para realizar la migración.",{"title":104,"body":105},"Reconfigurar el puerto y reiniciar","Tras la migración, apunta tu aplicación al clúster PG 18. Si conservas el puerto 5432, edita `\u002Fetc\u002Fpostgresql\u002F18\u002Fmain\u002Fpostgresql.conf`:\n\n```bash\nport = 5432\n```\n\nInicia la instancia PG 18:\n\n```bash\nsystemctl start postgresql@18-main\n```\n\nVerifica la versión activa:\n\n```bash\npsql -U postgres -c \"SELECT version();\"\n```",{"title":107,"body":108},"Analizar y limpiar tras la migración","Tras `pg_upgrade`, reconstruye las estadísticas en todas las bases de datos:\n\n```bash\nvacuumdb --all --analyze-in-stages -U postgres\n```\n\nUna vez validado, puedes eliminar el clúster antiguo y sus paquetes:\n\n```bash\n\u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin\u002Fpg_dropcluster 17 main\napt remove postgresql-17\n```",{"type":36,"title":110,"body":111},"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.",{"type":43,"title":113,"items":114},"Comandos de diagnóstico de versión",[115,116,117,118,119],"**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 \u003Ccontainer> psql -U postgres -c \"SELECT version();\"` para una instancia en contenedor.","**Vía pg_lsclusters** (Debian\u002FUbuntu): `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.",{"type":36,"title":121,"body":122},"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:\n\n- **Finales de octubre 2026**: GA de PG 19, primeros paquetes PGDG disponibles.\n- **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.\n- **Enero–febrero 2027**: primer parche de mantenimiento de PG 19. Esta es la señal estándar para considerar pruebas en staging.\n- **T1–T2 2027**: calificación en una instancia de staging con un volcado de producción anonimizado, validación de extensiones, pruebas de rendimiento.\n- **T2–T3 2027**: migración a producción para los equipos que hayan completado el ciclo completo de validación.\n\nTres precauciones que nunca hay que saltarse:\n\n1. **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.\n2. **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.\n3. **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.",{"type":36,"title":124,"body":125},"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.",{"type":91,"title":127,"steps":128},"Desplegar PG 18 en un VPS con Docker Compose",[129,132,135],{"title":130,"body":131},"Crear el archivo docker-compose.yml para PG 18","Crea un directorio dedicado y el archivo de configuración:\n\n```bash\nmkdir -p \u002Fopt\u002Fpostgres18 && cd \u002Fopt\u002Fpostgres18\n```\n\nContenido del `docker-compose.yml`:\n\n```bash\ncat > docker-compose.yml \u003C\u003C 'EOF'\nservices:\n  postgres:\n    image: postgres:18\n    container_name: postgres18\n    restart: unless-stopped\n    environment:\n      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}\n      POSTGRES_USER: ${POSTGRES_USER:-postgres}\n      POSTGRES_DB: ${POSTGRES_DB:-app}\n    volumes:\n      - .\u002Fdata:\u002Fvar\u002Flib\u002Fpostgresql\u002Fdata\n    ports:\n      - \"127.0.0.1:5432:5432\"\nEOF\n```\n\nCrea un archivo `.env` con tus valores:\n\n```bash\necho 'POSTGRES_PASSWORD=contraseña_segura_aquí' > .env\n```",{"title":133,"body":134},"Importar los datos desde la instancia antigua","Inicia el nuevo contenedor:\n\n```bash\ndocker compose up -d\n```\n\nRestaura el volcado desde tu instancia antigua (PG 16 o PG 17):\n\n```bash\npsql -U postgres -h 127.0.0.1 -p 5432 \u003C \u002Fbackup\u002Fpg_full_$(date +%Y%m%d).sql\n```\n\nVerifica que las bases de datos y tablas estén presentes:\n\n```bash\ndocker exec postgres18 psql -U postgres -l\n```",{"title":136,"body":137},"Verificar y cambiar la aplicación","Antes de cambiar la aplicación, verifica la versión activa en el contenedor:\n\n```bash\ndocker exec postgres18 psql -U postgres -c \"SELECT version();\"\n```\n\nActualiza la variable `DATABASE_URL` (o `DB_HOST`\u002F`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.",{"type":50,"title":139,"body":140},"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.",{"type":36,"title":142,"body":143},"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.\n\nLa ventana de acción es ahora, antes de la GA de PG 19:\n\n- 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.\n- 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.\n- 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.\n\nEl calendario de migración se decide cuando las opciones están abiertas, no cuando la presión operativa cierra las puertas.","Prueba PG 18 en un VPS con acceso root","Un VPS con acceso root te permite desplegar PostgreSQL 18 junto a tu instancia de producción, validar tu stack antes de cambiar, y revertir sin depender de un proveedor. Ese es el margen operativo que el hosting compartido no da.","Ver planes VPS","\u002Fvps-cloud",[149,165,180,198,220],{"id":150,"slug":151,"slugs":152,"title":156,"excerpt":157,"readTime":158,"views":18,"isPinned":19,"publishedAt":159,"updatedAt":160,"category":161,"categories":162,"featuredImage":30,"bgImage":31,"posterImage":164,"relatedSolution":30},315,"migrar-postgresql-15-a-17-en-una-stack-docker",{"fr":153,"en":154,"ar":155,"es":151},"postgresql-15-17-migration-docker-vps","migrating-postgresql-15-to-17-in-a-docker-stack","ترقية-postgresql-من-الإصدار-15-إلى-17-في-docker","Migrar PostgreSQL 15 a 17 en una stack Docker","Guía completa para migrar PostgreSQL 15 a 17 en Docker: pg_dump\u002Fpg_restore, extensiones incompatibles, checklist zero-downtime — y el caso Supabase.",12,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[163],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fpostgresql-15-17-migration-docker-vps-poster.svg",{"id":166,"slug":167,"slugs":168,"title":172,"excerpt":173,"readTime":174,"views":18,"isPinned":19,"publishedAt":175,"updatedAt":160,"category":176,"categories":177,"featuredImage":30,"bgImage":31,"posterImage":179,"relatedSolution":30},225,"postgresql-fin-de-vida-planificar-actualizacion",{"fr":169,"en":170,"ar":171,"es":167},"postgresql-fin-de-vie-planifier-montee-version","postgresql-end-of-life-plan-your-major-upgrade","postgresql-ونهاية-الدعم-تخطيط-الترقية-الكبرى","PostgreSQL en fin de vida: planificar la actualización mayor","PostgreSQL mantiene cada versión mayor cinco años, hasta su fin en noviembre. Identifique la suya y planifique la actualización sin perder datos.",4,"2026-08-05T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[178],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fpostgresql-fin-de-vie-planifier-montee-version-poster.svg",{"id":181,"slug":182,"slugs":183,"title":187,"excerpt":188,"readTime":174,"views":18,"isPinned":19,"publishedAt":189,"updatedAt":190,"category":191,"categories":192,"featuredImage":30,"bgImage":31,"posterImage":194,"relatedSolution":195},56,"alojar-postgresql-en-un-vps",{"fr":184,"en":185,"ar":186,"es":182},"heberger-postgresql-vps","postgresql-on-a-vps-a-reliable-and-controlled-database","postgresql-على-خادم-vps-قاعدة-بيانات-موثوقة-ومتحكم-بها","PostgreSQL en VPS: base de datos fiable y controlada","Aloje PostgreSQL en un VPS: volúmenes, copias de seguridad, acceso de red restringido y configuración sólida para sus aplicaciones.","2026-04-25T00:00:00+00:00","2026-09-08T22:00:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[193],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":196,"appSlug":197},"bases-de-datos","postgresql-stack",{"id":199,"slug":200,"slugs":201,"title":205,"excerpt":206,"readTime":207,"views":208,"isPinned":19,"publishedAt":209,"updatedAt":210,"category":211,"categories":215,"featuredImage":30,"bgImage":31,"posterImage":217,"relatedSolution":218},3,"instalar-n8n-en-vps-con-docker",{"fr":202,"en":203,"ar":204,"es":200},"installer-n8n-vps","install-n8n-on-vps-with-docker-complete-2026-guide","تثبيت-n8n-على-vps-مع-docker-دليل-شامل-2026","Instalar n8n en un VPS con Docker: guía completa 2026","Despliegue n8n en VPS con Docker, reverse proxy y HTTPS. Crash V8, 502 nginx, migración de npm a Docker y seguridad de ejecuciones persistidas (advisory agosto 2026).",16,2,"2026-06-05T00:00:00+00:00","2026-09-23T15:23:17+00:00",{"id":208,"name":212,"slug":213,"color":214,"icon":213},"Automatización","automatisation","bg-brand-action\u002F10 text-brand-action",[216],{"id":208,"name":212,"slug":213,"color":214,"icon":213},"\u002Fblog\u002Fcovers\u002Finstaller-n8n-vps-poster.svg",{"categorySlug":219,"appSlug":67},"automatizacion",{"id":221,"slug":222,"slugs":223,"title":227,"excerpt":228,"readTime":17,"views":18,"isPinned":19,"publishedAt":229,"updatedAt":160,"category":230,"categories":231,"featuredImage":30,"bgImage":31,"posterImage":233,"relatedSolution":234},60,"alojar-supabase-en-un-vps",{"fr":224,"en":225,"ar":226,"es":222},"heberger-supabase-vps","hosting-supabase-on-a-vps","استضافة-supabase-على-خادم-vps","Alojar Supabase en un VPS en 2026","Autoaloje Supabase en su VPS: Postgres, Auth, Storage y API REST con Envoy Gateway. Migración Kong→Envoy, solución de problemas de URLs S3.","2026-04-21T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[232],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-supabase-vps-poster.svg",{"categorySlug":196,"appSlug":235},"supabase",1790385862884]