Introducción
⏱️ Lectura: 13 min
El 27 de abril de 2026, una de las herramientas más respetadas del ecosistema PostgreSQL llegó a su fin: pgBackRest archivado oficialmente por su creador, David Steele. Tras trece años de desarrollo continuo, miles de despliegues en producción y una reputación intachable como la solución de backup y restore más robusta para PostgreSQL a escala, el repositorio en GitHub pasó al estado read-only. La versión v2.58.0 será la última estable del proyecto.
📑 En este artículo
- Introducción
- Qué pasó: pgBackRest archivado el 27 de abril de 2026
- Contexto e historia: 13 años construyendo el estándar de backup en PostgreSQL
- Datos y cifras: 3.800 estrellas, 4.809 commits y v2.58 como última versión
- Impacto y análisis: qué pierde la comunidad PostgreSQL
- Qué sigue: forks, alternativas y planes de migración
- Reflexión final: el costo invisible del software libre
- Preguntas frecuentes
- ¿pgBackRest seguirá funcionando si lo tengo instalado?
- ¿Hay alguna alternativa que sea drop-in replacement?
- ¿Por qué David Steele archivó el proyecto en lugar de pasárselo a alguien?
- ¿Existe algún fork oficial que la comunidad esté impulsando?
- ¿Cómo migro mis backups históricos a otra herramienta?
- ¿Conviene esperar a un fork o migrar ahora?
- Referencias
La noticia llega como un golpe inesperado para la comunidad PostgreSQL latinoamericana, donde pgBackRest era la opción por defecto en bancos, retailers y empresas de telecomunicaciones que manejan bases de datos de varios terabytes. En un comunicado titulado Notice of Obsolescence, Steele explica que tras la venta de Crunchy Data —su empleador histórico— no logró encontrar un patrocinio que le permitiera seguir dedicándole tiempo completo al proyecto.
El cierre marca el final de una era para los DBAs que dependían de pgBackRest para backups paralelos, restauraciones masivas y verificación de checksums a nivel de página. Hoy revisamos qué pasó, qué significa para PostgreSQL en LATAM y qué alternativas existen en 2026.
Qué pasó: pgBackRest archivado el 27 de abril de 2026
El cambio fue silencioso pero contundente. El repositorio pgbackrest/pgbackrest en GitHub apareció con la etiqueta Public archive y la leyenda This repository was archived by the owner on Apr 27, 2026. It is now read-only. Junto con el cambio de estado, Steele publicó un README extenso explicando los motivos.
El comunicado oficial es brutalmente honesto. Steele afirma que pgBackRest fue su passion project durante los últimos trece años y que tuvo patrocinio corporativo durante buena parte de ese tiempo. Sin embargo, después de que Crunchy Data —la empresa que durante años financió su trabajo— fuera vendida, el desarrollador buscó nuevas posiciones que le permitieran continuar el mantenimiento del proyecto. No las encontró. Tampoco logró asegurar el patrocinio externo que necesitaba para sostenerlo.
Steele cierra con una frase que resume el dilema del software libre en 2026: como todos, necesito ganarme la vida, y el rango de roles relacionados con pgBackRest es muy limitado. Con el cierre, deja abierta la puerta a un fork comunitario, pero advierte que será un proyecto nuevo, con mantenedores nuevos, y que tendrán que construir confianza desde cero.
Contexto e historia: 13 años construyendo el estándar de backup en PostgreSQL
pgBackRest nació en 2013 como una alternativa a las limitaciones de herramientas como pg_basebackup y pg_dump a escala empresarial. Steele creó el proyecto frustrado con el tiempo que tomaba respaldar bases de datos de varios terabytes: la compresión era el cuello de botella y las herramientas estándar no aprovechaban múltiples cores.
La solución de pgBackRest fue radical para la época: backup paralelo con compresión moderna (lz4 y zstd), un protocolo personalizado para evitar exponer PostgreSQL directamente a la red, y soporte para repositorios múltiples (uno local rápido para restauraciones inmediatas, uno remoto para retención larga). Estas decisiones de diseño fueron las que le ganaron adopción masiva.
Para 2026, pgBackRest se había convertido en el estándar de facto en bancos, gobiernos y empresas de telecomunicaciones de Latinoamérica. La razón era simple: en bases de datos de 10 TB o más, ninguna otra herramienta open source ofrecía la combinación de paralelismo, integridad y simplicidad operacional que pgBackRest entregaba. La integración con TLS y SSH para operación remota y la verificación de checksums por página lo hicieron especialmente popular en sectores regulados.
Crunchy Data y el patrocinio corporativo
Crunchy Data, una de las empresas más reconocidas del ecosistema PostgreSQL, fue durante muchos años el principal sustento financiero de pgBackRest. Steele trabajaba en Crunchy y dedicaba tiempo pago al proyecto. Cuando la empresa fue vendida —Steele no detalla el comprador en el comunicado— ese arreglo terminó.
El caso refleja un patrón que la comunidad open source ya conoce de memoria: proyectos críticos de infraestructura sostenidos por una sola persona o por una sola empresa que se vuelven invisibles hasta que se rompen o desaparecen. La famosa tira cómica de XKCD #2347 sobre la dependencia de toda la web en una librería mantenida por un voluntario aleatorio en Nebraska se cumple, una vez más, en el mundo de bases de datos.
Datos y cifras: 3.800 estrellas, 4.809 commits y v2.58 como última versión
Las métricas del repositorio al momento del archivado dimensionan el alcance del proyecto:
- 3.800 estrellas en GitHub.
- 276 forks activos.
- 4.809 commits a lo largo de 13 años (un promedio cercano a 370 commits por año).
- v2.58.0 como última versión estable.
- Soporte oficial para PostgreSQL desde 9.1 hasta las versiones más recientes.
- Implementado en C, con build system basado en Meson.
⚠️ Ojo: el archivado significa que GitHub seguirá hospedando el código en modo read-only, pero no habrá más parches de seguridad ni correcciones de bugs. Si tu organización depende de pgBackRest en producción, este es el momento de planear la migración o monitorear forks comunitarios serios.
Para poner los números en contexto: 4.809 commits en 13 años es un ritmo sostenido de desarrollo profesional. Comparado con muchos proyectos open source que viven de spurts esporádicos, pgBackRest mantuvo un cadence cercano al de un producto comercial, con releases frecuentes, changelogs detallados y soporte explícito para versiones nuevas de PostgreSQL en pocas semanas tras cada major release.
Características técnicas que lo hicieron único
Más allá del paralelismo, pgBackRest tenía un arsenal técnico difícil de igualar:
- Backups full, diferenciales e incrementales a nivel de archivo o de bloque. Los incrementales a nivel de bloque ahorraban espacio significativo en bases de datos donde solo cambia una fracción de los datos.
- Validación de checksums de página de PostgreSQL durante el backup, lo que permitía detectar corrupción a nivel de página antes de que llegara al backup.
- Cifrado AES-256-CBC en el repositorio para proteger los datos en reposo.
- Almacenamiento compatible con S3, Azure Blob, GCS y NFS, además de filesystem local.
- Operación delta restore: restaurar solo los archivos que cambiaron desde un punto de tiempo, ahorrando horas en restauraciones de desastres.
- Point-in-Time Recovery (PITR) con archivado WAL eficiente y rotación automática.
Impacto y análisis: qué pierde la comunidad PostgreSQL
El impacto de tener pgBackRest archivado es mayor de lo que parece a primera vista. Para empezar, no existe en el ecosistema open source una alternativa con cobertura funcional 1:1. Las opciones que quedan tienen tradeoffs serios y, en muchos casos, requieren reescribir scripts, runbooks y documentación interna que las áreas de DBA llevan años puliendo.
El caso más doloroso es el de las organizaciones reguladas. Bancos en Argentina, México y Colombia que escogieron pgBackRest justamente por su capacidad de validar checksums por página y por su trazabilidad ahora tienen que justificar ante auditoría una migración —o quedarse en una herramienta sin soporte oficial. Ninguna de las dos opciones es indolora, y los plazos regulatorios para reportar el cambio de stack son típicamente cortos.
El elefante en la sala: ¿quién paga el mantenimiento?
El cierre de pgBackRest reabre la conversación sobre cómo se financian las herramientas críticas de infraestructura. Steele lo dice sin rodeos: 13 años de pasión no se sostienen con late nights y weekends si encima hay que pagar la renta. La comunidad LATAM, que durante años usó pgBackRest sin contribuir económicamente, también tiene que mirarse al espejo: el descuento implícito de es open source y gratis terminó costándole su mantenedor.
💭 Clave: el modelo de una persona mantiene la pieza crítica de infraestructura es insostenible. Ya pasó con OpenSSL antes de Heartbleed, con log4j en 2021 y ahora con pgBackRest. La industria sabe el patrón pero rara vez actúa hasta que duele.
Qué sigue: forks, alternativas y planes de migración
Steele anticipó que el proyecto será forkeado. Es lo más probable: con 276 forks ya existentes y una base de usuarios global, alguna empresa o consorcio tomará la posta. Sin embargo, advierte que los nuevos mantenedores tendrán que construir confianza de la misma manera que nosotros lo hicimos. En otras palabras: forkear es trivial, mantener un fork con la calidad de pgBackRest no lo es.
Mientras eso pasa, las alternativas viables en 2026 son:
Barman
Mantenida por EnterpriseDB, Barman ofrece backup remoto, retención y PITR. La curva de aprendizaje es menor que pgBackRest pero el rendimiento en bases de datos de varios terabytes es más bajo. Para bases de hasta 1-2 TB es una alternativa razonable y bien documentada, con soporte comercial disponible si la organización lo necesita.
WAL-G
Un proyecto open source con foco en backup hacia object storage (S3, Azure Blob, GCS). Es más liviano que pgBackRest, soporta cifrado y compresión, pero carece de varias features avanzadas como validación de checksums de página y operación delta restore. Su comunidad es activa y su código en Go lo hace más accesible para contribuir, lo que es un activo en un mundo post-pgBackRest.
pg_basebackup + scripts personalizados
La opción más conservadora: usar la herramienta oficial de PostgreSQL y construir alrededor lo que falte. Funciona para bases pequeñas pero no escala. Salvo que tu base sea menor a 100 GB y aceptes ventanas de backup largas, no es una buena alternativa para producción seria.
Soluciones comerciales
EDB Backup and Recovery Tool (BART) y otras soluciones propietarias existen, pero implican costo y vendor lock-in. Para muchas empresas LATAM, el motivo de usar pgBackRest era justamente evitar esos dos puntos. Migrar de un open source maduro a un comercial cerrado es un retroceso que no todos los equipos están dispuestos a aceptar.
Plan de migración recomendado
Si actualmente usás pgBackRest en producción, la recomendación es la siguiente. Los comandos sirven igual en Linux y en WSL2 sobre Windows; en macOS, WAL-G se instala con Homebrew (brew install wal-g) o compilando desde el repositorio oficial.
# 1. Validar el backup mas reciente
pgbackrest --stanza=mi_db --log-level-console=info verify
# 2. Generar un manifest del estado actual
pgbackrest --stanza=mi_db info --output=json > pgbackrest_state.json
# 3. Probar la herramienta alternativa en staging (Linux / WSL2)
wget https://github.com/wal-g/wal-g/releases/latest/download/wal-g-pg-ubuntu-22.04-amd64.tar.gz
tar -xzf wal-g-pg-ubuntu-22.04-amd64.tar.gz
sudo mv wal-g-pg-ubuntu-22.04-amd64 /usr/local/bin/wal-g
# macOS
# brew install wal-g
# 4. Configurar la nueva herramienta y correr ambas en paralelo
# durante al menos 2 semanas antes de desactivar pgBackRest
# 5. Practicar restauracion desde la nueva herramienta en staging
# antes de cualquier corte definitivo
Diagrama: flujo de migración recomendado
graph LR
A["pgBackRest v2.58 en produccion"] --> B["Verificar backups actuales"]
B --> C["Elegir alternativa (WAL-G / Barman)"]
C --> D["Probar en staging por 2 semanas"]
D --> E["Correr ambas en paralelo"]
E --> F["Validar restore desde nueva tool"]
F --> G["Desactivar pgBackRest"]💡 Tip: no tengas prisa. pgBackRest seguirá funcionando exactamente igual mañana que hoy. El riesgo no es inmediato; es acumulativo conforme aparezcan vulnerabilidades en dependencias o cambios en versiones futuras de PostgreSQL que ya no tendrán parche oficial. Tomate 3-6 meses para una migración bien hecha.
Reflexión final: el costo invisible del software libre
El cierre de pgBackRest deja una lección incómoda. Durante 13 años, miles de empresas usaron una herramienta crítica sin pagar nada por ella. Cuando el sustento del único mantenedor desapareció, el proyecto entero se detuvo. No hubo conspiraciones ni dramas: simplemente, las cuentas no daban.
Para 2026, la conversación sobre cómo financiar la infraestructura abierta tiene que cambiar. GitHub Sponsors, Open Collective, contratos corporativos directos con mantenedores: todas son opciones que la mayoría de empresas LATAM aún no consideran como parte de su presupuesto técnico. Y mientras eso no cambie, vamos a seguir viendo proyectos como pgBackRest decir hasta acá llegamos.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿pgBackRest seguirá funcionando si lo tengo instalado?
Sí. El archivado de un repo en GitHub solo congela el código en modo read-only. La versión 2.58.0 que tengas en producción seguirá funcionando indefinidamente. Lo que no recibirás más son parches de seguridad, correcciones de bugs ni soporte para nuevas versiones mayores de PostgreSQL.
¿Hay alguna alternativa que sea drop-in replacement?
No. Ninguna herramienta actual replica 1:1 las features de pgBackRest. WAL-G se acerca para muchos casos de object storage, Barman es buena para bases medianas, y pg_basebackup sirve solo para bases pequeñas. Cada migración requiere análisis caso por caso según el tamaño de la base, la política de retención y los requerimientos regulatorios.
¿Por qué David Steele archivó el proyecto en lugar de pasárselo a alguien?
Steele explicó que prefiere un cierre limpio antes que un mantenimiento esporádico de baja calidad. Además, transferir un proyecto de esta criticidad requiere encontrar mantenedores con experiencia comprobada, algo que tampoco apareció. Dejó la puerta abierta a forks comunitarios, pero serán proyectos nuevos con mantenedores nuevos.
¿Existe algún fork oficial que la comunidad esté impulsando?
Al momento del cierre (27 de abril de 2026) no hay un fork comunitario consolidado. Es probable que en las próximas semanas alguna empresa del ecosistema PostgreSQL anuncie un fork con compromiso de mantenimiento. Hasta entonces, no recomendamos forks ad-hoc para producción.
¿Cómo migro mis backups históricos a otra herramienta?
Los backups históricos de pgBackRest no son portables a otras herramientas. La estrategia recomendada es retener los backups antiguos en su formato actual mientras dure su política de retención, y empezar a generar backups nuevos con la herramienta sustituta en paralelo. Después de cumplir la retención, los backups antiguos pueden archivarse o eliminarse de forma controlada.
¿Conviene esperar a un fork o migrar ahora?
Si tenés tiempo y recursos, migrar ahora es lo más prudente. Esperar un fork sin garantías de que aparezca en plazo razonable —y de que sea mantenido con la misma calidad— es asumir un riesgo operativo. La buena noticia es que la migración no es urgente: pgBackRest 2.58 funciona bien y seguirá funcionando.
Referencias
- pgBackRest en GitHub (archivado) — Repositorio oficial con el comunicado de archivado y código source completo.
- WAL-G en GitHub — Alternativa open source para backup de PostgreSQL hacia object storage.
- Barman en GitHub — Solución de backup mantenida por EnterpriseDB.
- Documentación oficial de pg_basebackup — Herramienta nativa de PostgreSQL para backups.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios