Percona Operator PostgreSQL 3.0.0: Hard Fork completo
El Operador Percona PostgreSQL 3.0.0 se lanzó el 22 de mayo de 2026 y marca una ruptura limpia con su pasado: Percona dejó de depender del operador de Crunchy Data y completó un hard fork, convirtiéndolo en un proyecto totalmente independiente. El cambio más visible es la migración del API Group (upstream.pgv2.crunchy.com → upstream.pgv2.percona.com), que habilita la coexistencia con otros operadores en el mismo cluster de Kubernetes.
En 30 segundos
- Percona completó el hard fork de su operador PostgreSQL: ya no depende del código de Crunchy Data y tiene roadmap propio.
- El API Group cambió a
upstream.pgv2.percona.com, lo que permite correr Percona y Crunchy Operator en el mismo cluster sin conflictos. - Soporte para PostgreSQL 14.23 hasta 18.4, en GKE, EKS, AKS, OpenShift y Minikube.
- OLM namespace scoping llega a OpenShift: el operador ya puede trabajar en namespaces específicos en vez de todo el cluster.
- Breaking change: el upgrade directo desde 2.7.0 está eliminado. La ruta obligatoria es 2.7 → 2.8 o 2.9 → 3.0.
¿Qué es el Operador Percona PostgreSQL y por qué importa?
El Operador Percona para PostgreSQL es una herramienta open source que automatiza el ciclo de vida de bases de datos PostgreSQL en Kubernetes: aprovisionamiento, configuración, backups con pgBackRest, alta disponibilidad con Patroni, y monitoreo. No reemplaza a PostgreSQL; lo gestiona. Si alguna vez tuviste que configurar manualmente réplicas de Postgres en un cluster de Kubernetes, sabés el dolor de cabeza que eso es (y por qué herramientas como esta existen).
Con la versión 3.0.0, según el anuncio oficial de Percona, el proyecto ya no es un fork suave que heredaba cambios de Crunchy Data: es una rama completamente independiente con su propia cadencia de releases, sus propias imágenes de contenedor y su propio rumbo técnico.
De soft fork a hard fork: el cambio que más importa
Durante años, el operador de Percona fue esencialmente una capa sobre el PGO de Crunchy Data. Percona le agregaba sus herramientas de monitoreo, sus imágenes de Percona Distribution for PostgreSQL, y algunas customizaciones, pero el núcleo era Crunchy. Eso tiene ventajas (te subís a los avances del upstream) pero también desventajas concretas: si Crunchy cambia algo que no te conviene, lo heredás igual.
Con el hard fork, Percona corta esa dependencia. ¿Qué significa en la práctica? Que el equipo de Percona ahora controla el 100% del código, puede priorizar features que importan a sus usuarios sin esperar al roadmap de otro, y puede tomar decisiones de arquitectura sin compatibilidad forzada con otra base de código. El riesgo que asumen es que también tienen que mantenerlo todo por su cuenta (que no es poca carga para un equipo de ingeniería).
Para los usuarios, el impacto más directo es el cambio de API Group. Los Custom Resource Definitions ahora viven bajo upstream.pgv2.percona.com en vez de upstream.pgv2.crunchy.com. Eso parece un detalle, pero tiene una consecuencia importante: ya podés correr el operador de Percona y el de Crunchy en el mismo cluster de Kubernetes sin que se pisen los recursos.
Cambios técnicos principales en 3.0.0
Más allá del hard fork, hay cambios concretos que impactan en cómo operás el sistema. Lo explicamos a fondo en herramientas de despliegue automatizado.
Nueva imagen oficial de upgrades
Percona introduce percona/percona-distribution-postgresql-upgrade como imagen oficial para los upgrades de major version. Antes esto dependía de imágenes de Crunchy; ahora Percona tiene el control total del proceso de upgrade de 14→15, 15→16, etc. La migración de CRDs durante el upgrade es automática: el operador detecta la versión vieja y convierte los recursos al nuevo schema sin intervención manual.
OLM namespace scoping en OpenShift
Si usás OpenShift con Operator Lifecycle Manager, la 3.0.0 trae namespace scoping real. Antes, el operador tenía que trabajar a nivel de cluster completo, lo que generaba problemas de permisos y aislamiento en entornos multi-tenant. Ahora podés desplegarlo restringido a namespaces específicos, lo que encaja mucho mejor con los modelos de seguridad que usan la mayoría de las empresas en producción.
Versiones de PostgreSQL soportadas
La 3.0.0 soporta PostgreSQL 14.23, 15.18, 16.14, 17.10 y 18.4. Las plataformas certificadas son GKE, EKS, AKS, OpenShift 4.14+ y Minikube (para desarrollo local). Nada de soporte para versiones EOL de Postgres, lo que tiene sentido.
Coexistencia con Crunchy Data Operator
Ponele que tenés un cluster de Kubernetes donde ya corrés PGO de Crunchy y querés evaluar el operador de Percona sin tirar abajo lo que tenés. Con la 3.0.0, eso es posible gracias al cambio de API Group. Los CRDs ya no colisionan porque están en namespaces de API distintos.
Las diferencias clave entre ambos operadores, más allá del código base:
| Aspecto | Percona Operator 3.0.0 | Crunchy PGO |
|---|---|---|
| Imágenes de contenedor | Percona Distribution for PostgreSQL | Crunchy Postgres |
| Monitoreo incluido | PMM (Percona Monitoring and Management) | pgMonitor |
| Licencia | Apache 2.0 | Apache 2.0 |
| Soporte comercial | Percona (pago) | Crunchy Data (pago) |
| OLM namespace scoping | Sí (desde 3.0.0) | Limitado |
| API Group | upstream.pgv2.percona.com | upstream.pgv2.crunchy.com |
La ruta de migración gradual existe: podés migrar namespace por namespace, dejando los clusters de Crunchy intactos mientras probás Percona en namespaces nuevos. No hay un botón mágico de migración automática entre operadores distintos (y si alguien te dice que sí hay, tomalo con pinzas).
Proceso de actualización: breaking changes y ruta obligatoria
Acá viene lo importante para quien ya corre versiones anteriores.
El soporte para actualización directa desde 2.7.0 fue eliminado. Si estás en 2.7, tenés que pasar por 2.8 o 2.9 antes de poder ir a 3.0. La ruta es: 2.7.0 → 2.8.x o 2.9.x → 3.0.0. No hay atajos. Para más detalles técnicos, mirá procesos de integración continua.
Durante el upgrade, hay una breve disrupción en pgBackRest. Los backups se detienen momentáneamente mientras el operador migra la configuración. No es un outage de la base de datos, pero si tenés SLAs de backup estrictos, planificá la ventana de mantenimiento con cuidado.
Los certificados TLS se regeneran automáticamente durante el proceso. Esto puede generar alertas en tus sistemas de monitoreo (que vas a querer silenciar antes del upgrade, no después). También hay consideraciones de PITR (Point-in-Time Recovery): si tenés backups continuos con WAL archiving, validá que la cadena de WAL permanece íntegra después del upgrade antes de descartar los backups de la versión anterior.
Los pasos básicos pre-upgrade: backup completo verificado, checar que corrés 2.8 o 2.9, revisar los CRDs actuales, documentar la configuración del cluster. Post-upgrade: verificar que el operador reconoció todos los clusters, confirmar que los backups retomaron, revisar los certificados regenerados.
Alta disponibilidad mejorada con Patroni
El operador usa Patroni para la gestión de HA. La 3.0.0 mejora el failover automático con elección de líder basada en posición WAL: cuando el primario cae, Patroni elige el nuevo líder según cuál réplica tiene el WAL más avanzado, no simplemente la que responde primero. Eso reduce la probabilidad de pérdida de datos en failovers.
El monitoreo continuo de salud y la renovación de leases de Kubernetes están ajustados para evitar falsos positivos. ¿Y qué pasa si el failover automático no es lo que querés en ciertos casos? El operador permite configurar el modo manualmente por cluster, aunque la mayoría de los casos de producción quieren failover automático habilitado.
Comparativa con otros operadores PostgreSQL en Kubernetes
| Operador | HA Engine | Backup | Monitoring | OLM Support | Licencia |
|---|---|---|---|---|---|
| Percona 3.0.0 | Patroni | pgBackRest | PMM | Sí (namespace) | Apache 2.0 |
| CloudNativePG | Nativo | Barman Cloud | Prometheus | Parcial | Apache 2.0 |
| Zalando Postgres Operator | Patroni | WAL-G | Prometheus | No oficial | MIT |
| StackGres | Patroni | pgBackRest/WAL-G | Grafana stack | No | AGPL 3.0 |
| Crunchy PGO | Patroni | pgBackRest | pgMonitor | Limitado | Apache 2.0 |
CloudNativePG se ha convertido en una opción muy seria, especialmente porque es un proyecto CNCF con adopción creciente y un modelo de HA que no depende de Patroni. Zalando es la opción más usada históricamente pero viene quedándose atrás en features recientes. StackGres es interesante si querés un stack de observabilidad más completo de entrada, aunque la licencia AGPL puede ser un problema según tu contexto legal. Relacionado: SEO para sitios multiidioma.
El Operador Percona tiene sentido si ya usás otras herramientas Percona (PMM para monitoreo, Percona Distribution), si necesitás soporte comercial argentino o latinoamericano, o si querés los extras de Percona Distribution for PostgreSQL (parches de seguridad adicionales, extensiones curadas).
Errores comunes al actualizar
Actualizar directo desde 2.7.0 a 3.0.0. Ya lo mencionamos pero vale la pena repetirlo: la gente lo intenta igual y el operador falla. La ruta es 2.7 → 2.8 o 2.9, punto. No hay workaround.
No silenciar las alertas de certificados antes del upgrade. Los certs se regeneran y tus sistemas de alerta van a dispararse. Si no lo sabés de antemano, vas a perder tiempo investigando un “problema” que es parte normal del proceso.
Asumir que la migración de CRDs es instantánea. El operador migra los CRDs automáticamente, sí, pero tarda. Si tenés muchos clusters en el mismo namespace, el proceso puede demorar varios minutos. No canceles el proceso antes de que termine; dejarlo a mitad es peor.
Ignorar la cadena de WAL antes de descartar backups viejos. Después del upgrade, antes de marcar como “limpios” los backups de la versión anterior, verificá que el PITR funciona desde el nuevo operador. Recién ahí eliminá los respaldos viejos.
Preguntas Frecuentes
¿Qué cambios trae el Operador Percona PostgreSQL 3.0.0?
Los cambios principales son el hard fork completo de Crunchy Data, el cambio de API Group a upstream.pgv2.percona.com, OLM namespace scoping para OpenShift, la nueva imagen oficial de upgrades (percona/percona-distribution-postgresql-upgrade) y soporte para PostgreSQL 14.23 hasta 18.4. El upgrade directo desde 2.7.0 ya no está soportado; la ruta obligatoria es 2.7 → 2.8 o 2.9 → 3.0. Esto se conecta con lo que analizamos en infraestructura local sin APIs.
¿Cuál es la diferencia entre un hard fork y soft fork en este contexto?
Un soft fork toma cambios del proyecto original y los integra periódicamente, manteniendo dependencia del upstream. Un hard fork corta esa dependencia: el código base pasa a ser completamente independiente. Percona era un soft fork de Crunchy PGO; con 3.0.0 pasó a ser un hard fork, lo que le da control total del roadmap pero también toda la responsabilidad de mantenimiento.
¿Cómo actualizar de Percona 2.x a 3.0.0 sin downtime?
Primero, asegurate de estar en 2.8 o 2.9 (no en 2.7). Hacé un backup completo verificado. El upgrade del operador no implica downtime de la base de datos en sí, pero hay una breve interrupción de pgBackRest durante la migración de configuración. Los certificados se regeneran automáticamente. Post-upgrade, verificá la cadena de WAL antes de tocar los backups anteriores.
¿Puedo usar Percona y Crunchy Operator en el mismo cluster de Kubernetes?
Sí, desde la 3.0.0. El cambio de API Group (upstream.pgv2.percona.com vs upstream.pgv2.crunchy.com) elimina la colisión de CRDs que impedía la coexistencia. Esto es útil para migraciones graduales: podés dejar los clusters de Crunchy intactos y crear los nuevos con Percona.
¿Qué es OLM namespace scoping y por qué importa en OpenShift?
OLM (Operator Lifecycle Manager) es el mecanismo de OpenShift para gestionar el ciclo de vida de operadores. Namespace scoping significa que el operador puede operar restringido a namespaces específicos en vez de tener permisos de cluster completo. En entornos multi-tenant o con modelos de seguridad estrictos, esto es necesario para cumplir con las políticas de acceso mínimo requerido.
Conclusión
La 3.0.0 del Operador Percona para PostgreSQL no es un update incremental. El hard fork cambia la naturaleza del proyecto: ya no dependés de que Crunchy Data tome decisiones compatibles con lo que Percona quiere hacer. Para los usuarios actuales, el cambio más urgente es verificar la ruta de upgrade (2.7 → 2.8/2.9 → 3.0, no hay atajos) y planificar la ventana de mantenimiento con los certificados y la breve interrupción de pgBackRest en mente.
Para quienes están evaluando operadores PostgreSQL en Kubernetes, la coexistencia con Crunchy PGO y el OLM namespace scoping son dos features que reducen el riesgo de adopción. No tenés que apostar todo a un operador si todavía estás evaluando.
Si tu infraestructura corre en servidores propios o VPS (en donweb.com o en cloud), Kubernetes con un operador como este es una forma seria de gestionar Postgres sin operaciones manuales complejas. La 3.0.0 consolida a Percona como opción independiente y madura en ese espacio.
