Crecimiento sostenido en PostgreSQL: qué miden los datos de Vondra

septiembre 17, 2026 Alfonso Moreno | Sysadmin Senior 37 Visitas 9 min de lectura

Crecimiento sostenido en PostgreSQL: qué miden los datos de Vondra (y por qué te importa en tu servidor)

Tomas Vondra, committer de PostgreSQL, publicó el 15 de septiembre de 2026 un análisis longitudinal del proyecto: commits por semana, mensajes en pgsql-hackers, tamaño de los patches, número de committers activos. Los datos van de 1996 a hoy. La conclusión operativa es incómoda: PostgreSQL está más vivo que nunca, lo cual es excelente, pero también está creciendo más rápido que la capacidad de cualquier sysadmin individual de seguirlo.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué este post y no solo “traducir” el de Vondra

El artículo original de Vondra es un ejercicio cuantitativo: él mira sus propios gráficos, reconoce la historia para gente que ya está adentro del proyecto, y no pretende extraer recomendaciones. Acá la idea es otra: tomar esos números como evidencia de un cambio estructural en cómo se desarrolla PostgreSQL, y traducirlo a cosas concretas que un sysadmin o devops que opera un servidor con PG en 2026 debería ajustar en su cabeza.

Lo que Vondra mide sin decirlo es que la barrera de entrada al proyecto subió. Si tú administras un PostgreSQL en producción, eso tiene consecuencias: el release cycle se acelera, los features nuevos llegan más rápido, los parches críticos también, y la ventana de soporte de cada versión estable se va acortando.

Los números clave de Vondra

Estos son los datos del post original (vondra.me/posts/postgres-development-activity), con foco en lo que sirve para sysadmins:

Métrica	~1996-2010	~2010-2026	Tendencia
Commits por semana	~10-25	~50	2x
Committers activos	crecimiento lineal	~2x vs 2010	Consistente
Mensajes/día en pgsql-hackers	~25	~100 (picos 200)	4x
% mensajes con patch adjunto	~5% (2008)	~25%	5x
Tamaño total attachments/día	~100 kB	~2 MB	20x
Líneas en el repo (incluyendo SGML + tests)	~4.4 M inserts netos	~9 M totales	2x

La métrica que más me importa a tú como sysadmin es la última: el tamaño total del repositorio se duplicó desde 2010. Eso significa que la superficie de código que potencialmente interactúa con tu workload (planificador, parser SQL, replication, vacuum, storage layer) es mucho más grande. Más código significa más features, pero también más caminos por los que un bug crítico puede entrar.

Qué cambió estructuralmente en el desarrollo de PostgreSQL

El propio Vondra señala dos hitos que coinciden con inflexiones en las curvas: el commitfest (introducido en 2008, primera app desplegada en 2015) y la migración CVS → git (2010). No son causalidad probada pero el solapamiento es muy claro. El commitfest en particular cambió el ritmo de trabajo: en vez de patches llegando al árbol de manera dispersa todo el año, ahora se concentran bursts en marzo y septiembre, justo antes del feature freeze de cada major release.

Para el operador externo eso significa que el ciclo de releases de PostgreSQL se planifica de manera más disciplinada pero también más intensa. Cada major release (PG 17 en 2024, PG 18 que está en beta, PG 19 ya en planning) trae más features que la anterior porque hay más committers escribiendo más patches.

Cómo se ve eso en tu servidor

Cadencia de minor releases más seguida: si administras un PG en producción, antes podías actualizar una vez al año. Hoy te conviene seguir los minor releases trimestrales porque la actividad upstream es suficiente para que aparezcan parches de bajo riesgo pero alta urgencia (vacuum, replication, security).
Más features opt-in por versión: cada major release nuevo activa experimental features que en la siguiente versión se vuelven estables. Lo que era experimental en PG 16 (streaming I/O, ciertos JSON constructors) es default en PG 17.
Más vectores de tuning por workload: hace 10 años ajustar PostgreSQL eran 10-15 parámetros de postgresql.conf. Hoy la wiki oficial de tuning lista 40+ parámetros con efectos medibles, sin contar las extensiones que también crecieron (pg_stat_statements, pg_hint_plan, pg_partman, etc.).

El lado “demasiada actividad”: cómo filtrar lo relevante para tu servidor

Vondra también menciona el problema inverso: la pgsql-hackers lista se volvió prácticamente imposible de seguir. Si eres un contributor eso es un problema serio. Si eres sysadmin, el problema equivalente es: ¿cómo me entero de lo que me toca a mí sin leer 100 mensajes/día?

Fuentes curadas que sí escalan a tu ritmo de operador

PostgreSQL Security Advisories: la lista oficial de CVEs. Te llega por RSS si quieres. Esto es lo único que debería ser push inmediato.
pgsql-announce: la lista de releases. Volumen bajo (decenas de mensajes al año), alta señal. Suscribirse es prácticamente gratis.
commitfest.postgresql.org: el estado de cada patch en revisión. Si operas algo cerca del cutting edge, mira esto antes de actualizar para saber qué feature entra en qué release.

# Ejemplo: subscribirse a pgsql-announce vía RSS (curl + cron)
curl -s https://www.postgresql.org/list/pgsql-announce/rss/ 
  | grep -oE '[^<]+' 
  | tail -5

El bloque anterior baja el RSS, extrae los títulos y te muestra los últimos 5 anuncios. Sirve para confirmar de un vistazo qué versión se liberó y cuándo, sin tener que abrir la web. Si quieres enterarte al instante, apuntá este feed a tu agregador (Feedly, FreshRSS, Miniflux) en vez de curl.

Implicancia para tu actualización: el caso PG 16 → PG 17

Lo concreto que más vas a notar como sysadmin es que la ventana de upgrade entre major releases se está acortando. PG 16 todavía tiene soporte hasta noviembre 2028 (5 años desde release inicial), pero PG 17 ya está estable desde septiembre 2024 y trae mejoras que justifican el upgrade en varios workloads.

Si quieres el paso a paso completo de cómo instalar PG 17 en Ubuntu 24.04 ya lo cubrimos en detalle acá: Cómo instalar PostgreSQL 17 en Ubuntu 24.04: guía paso a paso. Lo que cambia con el análisis de Vondra es el calendario: si tienes un PG 12 o 13 en producción hoy, ya estás fuera de soporte y el próximo minor security fix no te va a llegar.

Cómo chequear qué versión tienes y cuándo se queda sin soporte

# Versión instalada en el server local
psql --version
# psql (PostgreSQL) 16.x (Ubuntu 16.x-...)
# Versión del cluster corriendo
sudo -u postgres psql -c "SHOW server_version;"
# Fecha de EOL de la versión (checkea la wiki oficial)
curl -s https://www.postgresql.org/support/versioning/ 
  | grep -A1 'Current' | head -20

El primer psql --version te dice qué cliente tienes en PATH (no necesariamente lo que corre el server). El segundo con SHOW server_version es lo que importa para saber si estás cubierto. La tercera línea confirma contra la wiki oficial cuándo se libera el último parche de tu versión.

Si tu versión está fuera de soporte (PG 12, 13, etc.), el plan mínimo es upgrade a la última estable disponible. No hay excusas: cada mes que pasa sin parches es un CVE potencial sin cobertura.

Cómo contribuir de vuelta al proyecto (si quieres)

Vondra menciona que la pgsql-hackers se volvió inmanejable. Eso tiene un lado bueno: cualquier mejora en la docs, en los tests, en la traducción, en reportar bugs bien formados tiene impacto. Si tu servidor usa PostgreSQL todos los días, contribuir un poco de vuelta es la forma más sana de asegurar que el proyecto no se quede sin mantenimiento.

Formas concretas que escalan a un sysadmin ocupado

Reportar bugs con un caso reproducible: si encontraste algo raro en PG 17 con un workload específico, mandalo a pgsql-bugs con un script mínimo que reproduzca el problema. Eso vale más que 10 parches mal hechos.
Actualizar traducciones: la documentación de PostgreSQL está en múltiples idiomas y siempre hay strings desactualizados. Si hablás español, puedes contribuir a la versión en español sin necesidad de saber C.
Comentar en pgsql-hackers: cuando alguien propone un patch que toca tu caso de uso, leelo y mandá feedback. Los maintainers valoran más el feedback de operadores reales que de otros developers que nunca corrieron PG en producción.

# Suscribirse a pgsql-bugs (volumen manejable)
curl -s https://www.postgresql.org/list/pgsql-bugs/rss/ 
  | grep -oE '[^<]+' 
  | head -10

El feed de pgsql-bugs es más bajo en volumen que pgsql-hackers y es donde aparecen los reportes que después se transforman en CVEs. Leer los títulos te lleva 5 minutos a la semana y te mantiene al tanto de qué clases de bugs están apareciendo en la versión que usas.

Resumen

PostgreSQL está más activo que nunca, con el doble de commits y el doble de committers que hace 15 años, y eso es una buena noticia y un riesgo a la vez. La buena: el proyecto está vivo, los bugs se arreglan rápido, los features nuevos llegan. El riesgo: el ciclo de releases se acelera y la ventana para actualizar sin sobresfuerzo se va acortando.

Como sysadmin, el plan mínimo en 2026 es:

Correr la última minor de una major supported (PG 13, 14, 15, 16 o 17).
Suscribirse a pgsql-announce y al feed de security advisories.
Tener un plan de upgrade de major version cada 2-3 años.
Medir tu propia base con pg_stat_statements y pg_stat_activity para saber cuándo te toca actualizar por presión de workload.

El post de Vondra no te dice nada de esto explícitamente, pero los números son la justificación. Si administras PostgreSQL en serio, el ritmo del upstream tiene que dictar tu propio ritmo de update.

Si quieres monitorear tu PG con algo práctico y open source, este post te puede servir: Prometheus y Grafana: tu propio stack de monitoring en 2026. Y para no perder los datos si algo sale mal: Restic vs Borg vs Kopia: comparativa de backups cifrados 2026.

Preguntas frecuentes

¿Por qué Crecimiento sostenido en PostgreSQL: qué miden los datos de Vondra es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Crecimiento sostenido en PostgreSQL: qué?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Crecimiento sostenido en PostgreSQL: qué?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Crecimiento sostenido en PostgreSQL: qué y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Crecimiento sostenido en PostgreSQL: qué?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.