Operador PostgreSQL Kubernetes: cuál elegir en 2026
En 2026, elegir un operador PostgreSQL Kubernetes se volvió más complicado que antes, y no por razones técnicas. Los cambios de licencia y restricciones en imágenes de los últimos 12 meses cambiaron las reglas del juego para equipos que necesitan saber qué pueden redistribuir, modificar y usar sin sorpresas legales.
En 30 segundos
- MinIO archivó su repositorio público el 25 de abril de 2026 tras migrar a AGPLv3; Bitnami deprecó imágenes Debian en agosto de 2025; Crunchy Data movió sus imágenes a un registro privado.
- Los tres operadores más usados son CloudNativePG (CNCF incubating), Crunchy PGO y Zalando Postgres Operator, cada uno con filosofía de diseño distinta.
- Percona lanzó un hard fork independiente de Crunchy PGO 3.0 con imágenes 100% open source y redistribuibles.
- CloudNativePG ejecuta la lógica de HA sin sidecars, con un Instance Manager en Go como PID 1; Crunchy PGO y Zalando usan Patroni como sidecar.
- La pregunta que más importa antes de elegir: ¿las imágenes del operador son redistribuibles públicamente sin restricciones comerciales?
El cambio de licencias open source en 2025-2026
Un operador PostgreSQL para Kubernetes es un controlador que automatiza el ciclo de vida completo de clústeres PostgreSQL dentro de un cluster de Kubernetes: aprovisionamiento, replicación, failover, backups y actualizaciones. Sin un operador, manejar PostgreSQL en producción sobre Kubernetes es básicamente hacerlo a mano, y eso escala mal.
Eso sí: no todos los operadores son iguales, y en 2026 la diferencia no pasa solo por features técnicas.
Lo que cambió es el ecosistema de imágenes y licencias alrededor de estos proyectos. Según el análisis de Percona publicado en abril de 2026, tres eventos marcaron el escenario actual:
- 25 de abril de 2026: MinIO archivó su repositorio público luego de mover el proyecto a AGPLv3. Cualquier equipo que usaba imágenes de MinIO en pipelines de backup necesitó revisar su posición legal.
- Agosto de 2025: Bitnami deprecó sus imágenes Debian. Afectó directamente a quienes usaban Bitnami Helm charts para PostgreSQL.
- 2025-2026: Crunchy Data movió sus imágenes de contenedor a un registro privado, con restricciones de redistribución que antes no existían.
El resultado: equipos que pensaban tener una solución “open source” descubrieron que las imágenes que usaban no eran libremente redistribuibles. (Spoiler: eso importa mucho si corrés on-premises, en un cloud propio, o vendés software que incluye PostgreSQL.)
Tres preguntas para evaluar cualquier operador
Gabriele Bartolini publicó en mayo de 2026 una comparación honesta que identifica tres criterios clave. Los resumo porque son el filtro real antes de ponerse a comparar features:
1. ¿Las imágenes son redistribuibles públicamente? No alcanza con que el código sea open source. Si las imágenes de contenedor están en un registro privado o tienen restricciones de uso comercial, no podés incluirlas en tu producto ni correrlas en todos los entornos sin más trámite.
2. ¿Las características operacionales clave (backup, HA, monitoreo) están disponibles en el build open source? Algunos proyectos ofrecen HA o backups solo en su versión enterprise. Si el operador gratuito no incluye failover automático, tenés que pagar o armar la solución vos mismo.
3. ¿La gobernanza y el roadmap son públicos? Un proyecto con gobernanza cerrada puede cambiar licencia o dirección sin previo aviso. Ya pasó. En al seleccionar tu herramienta de CI/CD profundizamos sobre esto.
CloudNativePG: arquitectura nativa, sin sidecars
CloudNativePG es el único operador PostgreSQL que actualmente está en incubación dentro de la Cloud Native Computing Foundation (CNCF). Eso no es solo un badge: implica gobernanza pública, código auditado por la comunidad y un proceso de decisiones abierto.
La diferencia arquitectónica más importante: CloudNativePG no usa sidecars para gestionar la alta disponibilidad. En cambio, corre un Instance Manager escrito en Go como PID 1 dentro del container de PostgreSQL. Ese binario maneja la replicación nativa de PostgreSQL, los switchovers, los failovers y la configuración, todo sin procesos auxiliares que puedan desincronizarse o generar overhead.
¿Por qué importa esto? Porque en Kubernetes, tener menos procesos por pod es generalmente mejor: menos superficie de fallo, menor uso de recursos, y modelos de debugging más simples.
Arrancás el pod, el Instance Manager negocia el rol (primary o standby), conecta la replicación y listo. Si el primary cae, el operador promueve un standby en segundos. Todo esto está en el build open source, sin necesidad de pagar una suscripción.
Las imágenes son 100% redistribuibles. Google GKE tiene documentación oficial de CloudNativePG, y Microsoft Azure también publicó soporte para PostgreSQL HA en AKS usando este operador.
Crunchy PGO: cambios de licencia y el hard fork de Percona
Crunchy PGO fue durante años la referencia de producción para PostgreSQL en Kubernetes. Usa Patroni como sidecar para manejar la HA, y tiene una base de usuarios grande y documentación extensa.
El problema es que en 2025 Crunchy Data movió sus imágenes oficiales a un registro privado con restricciones de redistribución. Para equipos que necesitan imágenes redistribuibles, eso rompió su modelo de uso.
Percona respondió con un hard fork real: Percona Operator for PostgreSQL 3.0, construido sobre PGO pero con imágenes 100% open source en registros públicos, sin restricciones comerciales. El fork mantiene compatibilidad con la API de Crunchy PGO, lo que en teoría facilita la migración. Percona también documenta una estrategia de migración basada en “clúster standby” que permite mover datos sin downtime, usando pgBackRest como formato de backup y Patroni para la gestión de HA.
¿El trade-off? Estás en un fork. El ecosistema original tiene más historia y más casos de uso documentados. El fork de Percona tiene menos tracción de comunidad hasta ahora, aunque el equipo detrás tiene credenciales serias en el espacio PostgreSQL. Relacionado: considerando la seguridad del código abierto.
Zalando Postgres Operator: Patroni a escala
Zalando opera miles de clústeres PostgreSQL en producción con su propio operador, y eso es en sí mismo una referencia. El operador usa Patroni como solución de HA, igual que Crunchy PGO, y tiene una comunidad activa con amplio soporte.
Donde brilla es en equipos que ya conocen Patroni, que quieren una solución madura probada a escala empresarial real, y que no dependen de las imágenes de Crunchy. Las imágenes del Zalando Operator son open source y redistribuibles.
El modelo de gobernanza es más informal que CloudNativePG, porque no está bajo una fundación. Eso implica que el roadmap depende más directamente de lo que Zalando necesite internamente, aunque el historial de contribuciones externas es bueno.
Comparativa técnica: arquitecturas y trade-offs
| Operador | HA mecanismo | Imágenes redistribuibles | Gobernanza | Backup incluido | Sidecars |
|---|---|---|---|---|---|
| CloudNativePG | Instance Manager nativo (Go, PID 1) | Sí, 100% | CNCF Incubating | Sí (barman-cloud) | No |
| Crunchy PGO | Patroni (sidecar) | Restricciones desde 2025 | Privada (Crunchy Data) | Sí (pgBackRest) | Sí |
| Percona PGO 3.0 | Patroni (sidecar) | Sí, 100% | Percona (fork abierto) | Sí (pgBackRest) | Sí |
| Zalando | Patroni (sidecar) | Sí | Zalando / comunidad | Parcial (WAL-G) | Sí |
La diferencia de arquitectura entre CloudNativePG y los demás no es cosmética. Los operadores basados en Patroni tienen un sidecar corriendo junto al contenedor de PostgreSQL, lo que significa que hay dos procesos que necesitan coordinarse para tomar decisiones de failover. CloudNativePG integra esa lógica dentro del mismo container, con el Instance Manager como proceso principal.
¿Eso hace que CloudNativePG sea automáticamente mejor? Depende. Si tu equipo tiene experiencia con Patroni en producción y ya tiene runbooks, alertas y muscle memory construidos alrededor de cómo Patroni se comporta cuando algo sale mal, cambiar a un modelo diferente tiene un costo de aprendizaje real.
Reversibilidad y migraciones sin downtime
Ponele que elegís un operador hoy y en dos años necesitás cambiar. ¿Qué tan atados quedás?
La buena noticia es que si el operador usa pgBackRest para backups (como Crunchy PGO y Percona PGO), el formato de backup es compatible entre operadores. Podés restaurar un backup de Crunchy en CloudNativePG o viceversa, siempre que las versiones de PostgreSQL sean compatibles. Complementá con ejecutar operadores sin depender de APIs.
Percona documenta la migración usando un “clúster standby”: levantás el nuevo operador apuntando al backup del operador viejo, dejás que sincronice, y cuando está al día hacés el switchover. En teoría, cero downtime. En la práctica, habría que ver con cargas de trabajo reales y volúmenes grandes.
Lo que garantiza la portabilidad es usar imágenes 100% open source desde el principio. Si las imágenes son redistribuibles, podés correr el mismo PostgreSQL en cualquier operador, en cualquier cloud, en cualquier infraestructura. Si estás usando imágenes de un registro privado, ese camino se cierra.
Si tu infraestructura corre en donweb.com u otro proveedor local, asegurate de verificar que el registro de imágenes sea accesible desde tu entorno antes de comprometerte con un operador.
Qué está confirmado y qué no
- Confirmado: MinIO archivó su repositorio público el 25 de abril de 2026 (anuncio oficial del proyecto).
- Confirmado: Bitnami deprecó imágenes Debian en agosto de 2025 (comunicado oficial de Bitnami).
- Confirmado: CloudNativePG es proyecto CNCF Incubating con gobernanza pública verificable.
- Confirmado: Percona lanzó fork independiente PGO 3.0 con imágenes redistribuibles.
- Sin verificación independiente: Las métricas de performance comparativas entre operadores que circulan en blogs; los benchmarks son generalmente del propio fabricante.
- Sin verificación independiente: Tiempos exactos de failover en cargas de trabajo de producción a escala; varían mucho según configuración de red, almacenamiento y carga.
Errores comunes al elegir un operador
Error 1: Asumir que “open source” en el nombre del proyecto significa imágenes redistribuibles. El código fuente puede estar en GitHub bajo Apache 2.0 y las imágenes del registry pueden tener restricciones completamente distintas. Son dos cosas separadas. Siempre revisá los términos del registry, no solo la licencia del repositorio.
Error 2: Elegir el operador por el nombre del cloud provider. “GKE tiene soporte oficial para X” no significa que X sea la mejor opción para tu carga de trabajo. Los cloud providers documentan lo que sus equipos probaron, no necesariamente lo que tiene mejor performance para tu caso específico.
Error 3: Ignorar la gobernanza del proyecto hasta que es tarde. Un proyecto sin fundación o con gobernanza cerrada puede cambiar licencia, mover imágenes o simplemente frenarse si la empresa detrás cambia de dirección. La historia reciente en este ecosistema tiene suficientes ejemplos. Antes de comprometerte, mirá: ¿quiénes son los maintainers? ¿hay diversidad de empresas contribuyendo? ¿el roadmap es público?
Error 4: No probar el proceso de failover antes de llegar a producción. Cada operador maneja el failover de manera diferente en cuanto a tiempos, condiciones y comportamiento con conexiones abiertas. Testealo con carga real en staging, no confíes en la documentación del vendor sobre tiempos de recuperación.
Preguntas Frecuentes
¿Qué operador PostgreSQL debo elegir para Kubernetes en 2026?
Si necesitás imágenes redistribuibles, gobernanza pública y HA sin sidecars, CloudNativePG es la opción más sólida en 2026. Si ya tenés experiencia con Patroni y querés evitar los problemas de redistribución de Crunchy PGO, el fork de Percona PGO 3.0 es una alternativa directa. Zalando es una buena opción si tu equipo ya tiene expertise en ese ecosistema y no necesitás cambiar. Sobre eso hablamos en al comparar plataformas open source.
¿Cuál es la diferencia técnica entre CloudNativePG y Crunchy PGO?
CloudNativePG usa un Instance Manager escrito en Go como PID 1 dentro del container de PostgreSQL para manejar la HA de forma nativa, sin sidecars. Crunchy PGO (y su fork Percona PGO) usan Patroni como sidecar para la gestión de HA. La diferencia práctica: CloudNativePG tiene menos procesos por pod y una integración más estrecha con el ciclo de vida de Kubernetes, mientras que los basados en Patroni tienen una comunidad más amplia y más runbooks de producción disponibles.
¿Puedo migrar entre operadores PostgreSQL sin downtime?
Sí, si usás pgBackRest como formato de backup y el nuevo operador puede leer ese formato. Percona documenta una estrategia de “clúster standby” donde levantás el nuevo operador sincronizando desde el backup del viejo, y hacés el switchover cuando están en sync. El éxito en producción depende del volumen de datos, la carga de escritura y la latencia de red.
¿Qué cambió en las licencias de operadores PostgreSQL en 2025-2026?
Tres eventos principales: Bitnami deprecó imágenes Debian en agosto de 2025, Crunchy Data movió sus imágenes a un registro privado con restricciones de redistribución, y MinIO archivó su repositorio público el 25 de abril de 2026 tras migrar a AGPLv3. El efecto es que varias soluciones que se usaban como “open source” sin pensar ahora requieren revisar términos legales antes de redistribuir o usar en producción.
¿Necesito un operador para correr PostgreSQL en Kubernetes?
Técnicamente no, podés correr PostgreSQL en Kubernetes con un StatefulSet básico. Pero sin un operador perdés failover automático, gestión de backups coordinada, y el ciclo de vida automatizado de la replicación. Para cualquier carga de trabajo de producción que no sea experimental, un operador es prácticamente obligatorio si querés evitar operar todo eso a mano.
Conclusión
Lo que cambió en 2026 no es la tecnología de fondo, sino el ecosistema de imágenes y licencias que rodea a los operadores. PostgreSQL sigue siendo PostgreSQL. Patroni sigue siendo Patroni. Pero la pregunta de qué podés usar, redistribuir y modificar sin sorpresas legales se volvió más relevante que la comparación feature por feature.
Si arrancás un proyecto nuevo hoy, CloudNativePG tiene la posición más limpia: CNCF, gobernanza pública, imágenes redistribuibles, arquitectura nativa de Kubernetes. Si venís de Crunchy PGO y los cambios de licencia te afectan, el fork de Percona PGO 3.0 es el camino natural de menor fricción. Y si ya tenés Zalando corriendo en producción y no tenés problemas de redistribución, no hay razón urgente para migrar.
La lección más amplia: revisá las condiciones de redistribución de tus imágenes antes de que ese sea el problema de otro equipo en producción un domingo.
Fuentes
- Percona Blog — Not All Open Source Is Equal: Choosing a PostgreSQL Operator for Kubernetes in 2026
- Gabriele Bartolini — CloudNativePG and Crunchy PGO: An Honest, Opinionated Comparison (mayo 2026)
- CloudNativePG — Sitio oficial del proyecto CNCF
- Google GKE — Tutorial CloudNativePG en Google Kubernetes Engine
- GitHub — Zalando Postgres Operator
