Hay una pregunta que muchos equipos de infraestructura evitan hacerse: si PostgreSQL es la base de datos open-source más utilizada del mundo, ¿por qué seguimos tratándola como si solo pudiera vivir en un servidor tradicional o en un servicio administrado genérico?
Azure ofrece Azure Database for PostgreSQL — un servicio administrado sólido. Pero hay escenarios donde un servicio PaaS no es suficiente. Cuando necesita control fino sobre la configuración del motor, cuando su arquitectura ya está en contenedores, o cuando los costos de un servicio administrado a escala se vuelven difíciles de justificar, la alternativa es ejecutar PostgreSQL directamente en Azure Kubernetes Service.
No es un ejercicio académico. Es una arquitectura de producción que Microsoft está documentando y optimizando activamente.
Por qué PostgreSQL en Kubernetes tiene sentido ahora
Durante años, ejecutar bases de datos con estado en Kubernetes era una mala idea. Los volúmenes persistentes eran inestables, los operadores eran inmaduros y la recuperación ante fallos era manual. Eso cambió.
Kubernetes ahora tiene primitivas maduras para cargas con estado: StatefulSets con identidades estables, volúmenes persistentes con provisionamiento dinámico, y un ecosistema de operadores que automatizan las operaciones de base de datos que antes requerían un DBA dedicado.
Para PostgreSQL específicamente, el operador CloudNativePG — desarrollado originalmente por EDB y ahora proyecto del CNCF — transforma la experiencia. CloudNativePG no es un wrapper genérico. Es un operador diseñado exclusivamente para PostgreSQL que maneja replicación, failover automático, backups continuos y rolling updates sin intervención manual.
La combinación de AKS + CloudNativePG significa que puede tener un clúster PostgreSQL de alta disponibilidad con réplicas de lectura, backup continuo a Azure Blob Storage y failover automático — todo declarado en archivos YAML y gestionado por Kubernetes.
Qué hace diferente a AKS para esta carga de trabajo
No todos los clústeres de Kubernetes son iguales para bases de datos. AKS tiene optimizaciones específicas que importan cuando la carga de trabajo es una base de datos con requisitos de rendimiento:
VMs optimizadas para almacenamiento. Azure ofrece familias de máquinas virtuales como la serie Ebdsv5 y Lsv3 que están diseñadas para cargas de I/O intensivo. Estas VMs tienen discos NVMe locales con latencias de submilisegundo y throughput que puede superar los 5 GB/s. Para PostgreSQL, donde el rendimiento de I/O es el factor limitante número uno, elegir el nodo correcto marca una diferencia medible.
Premium SSD v2 y Ultra Disk. AKS soporta clases de almacenamiento que usan Premium SSD v2, donde puede configurar IOPS y throughput de forma independiente. Esto significa que no está pagando por un paquete de rendimiento predefinido — ajusta exactamente lo que su carga de trabajo necesita. Para ambientes de producción con patrones de escritura intensiva, Ultra Disk ofrece hasta 160,000 IOPS por disco.
Aceleración de red. AKS habilita redes aceleradas por defecto en nodos compatibles, reduciendo la latencia de red entre pods y entre la aplicación y la base de datos. En una arquitectura donde la aplicación y PostgreSQL corren en el mismo clúster, esta optimización tiene impacto directo en los tiempos de respuesta de las consultas.
CloudNativePG: el operador que cambia la ecuación
Lo que hace viable ejecutar PostgreSQL en producción sobre Kubernetes es el operador. Sin un operador competente, estaría escribiendo scripts de failover y cron jobs para backups — exactamente el tipo de trabajo manual que Kubernetes debería eliminar.
CloudNativePG maneja las operaciones críticas:
- Alta disponibilidad. Replicación sincrónica o asincrónica con failover automático. Si el nodo primario falla, CloudNativePG promueve una réplica a primario en segundos, no en minutos.
- Backup continuo. Integración nativa con Azure Blob Storage para WAL archiving y backups base. Puede configurar retención por días o por cantidad, y los backups se ejecutan sin impacto en el rendimiento del clúster.
- Rolling updates. Actualizar la versión de PostgreSQL o cambiar la configuración del motor se hace con un cambio en el manifiesto de Kubernetes. CloudNativePG coordina el proceso réplica por réplica, sin downtime.
- Monitoreo integrado. Métricas expuestas en formato Prometheus, listas para ser consumidas por Azure Monitor, Grafana o cualquier stack de observabilidad.
El modelo declarativo es clave. Usted define el estado deseado — tres réplicas, backup cada hora, almacenamiento Premium SSD — y el operador se encarga de mantener ese estado. Si un pod falla, se recrea. Si un nodo se cae, los pods migran. El operador es el DBA automatizado.
Cuándo usar Azure Database for PostgreSQL vs. PostgreSQL en AKS
Esta no es una decisión binaria. Ambas opciones son válidas y dependen del contexto de cada organización.
Azure Database for PostgreSQL Flexible Server es la opción correcta cuando su equipo quiere delegar completamente la gestión del motor. Parches de seguridad, alta disponibilidad, backups y monitoreo vienen incluidos. Es ideal para equipos pequeños, aplicaciones SaaS estándar y escenarios donde el tiempo de salida al mercado es más importante que la personalización.
PostgreSQL en AKS tiene sentido cuando necesita control sobre la configuración del motor (parámetros de postgresql.conf que el servicio administrado no expone), cuando su aplicación ya corre en Kubernetes y quiere una arquitectura unificada, cuando necesita múltiples instancias de PostgreSQL con diferentes versiones o configuraciones, o cuando los costos del servicio administrado a escala se vuelven un problema.
También hay un tercer escenario que vemos con frecuencia: organizaciones que están migrando desde PostgreSQL on-premises y necesitan un paso intermedio. Ejecutar en AKS les permite replicar la configuración exacta que tenían en sus servidores físicos mientras adaptan la aplicación para la nube.
Si su empresa está evaluando esta decisión, nuestro equipo de consultoría tecnológica puede hacer un assessment de su carga de trabajo y recomendar la arquitectura que mejor se adapte a sus requerimientos de rendimiento, costo y operación.
Consideraciones prácticas para producción
Ejecutar PostgreSQL en AKS no es simplemente instalar un Helm chart y declarar victoria. Hay decisiones de arquitectura que afectan directamente la estabilidad y el rendimiento:
Afinidad de nodos. Los pods de PostgreSQL deben correr en nodos dedicados con taints y tolerations. No quiere que un deployment de aplicación compita por CPU y memoria con su base de datos.
Clase de almacenamiento. Defina una StorageClass específica para PostgreSQL que use Premium SSD v2 o Ultra Disk. El almacenamiento estándar no es aceptable para cargas de producción.
Límites de recursos. Configure requests y limits de CPU y memoria de forma conservadora. PostgreSQL necesita memoria predecible para shared_buffers y work_mem. Si Kubernetes mata un pod por OOM, pierde la réplica.
Red. Use network policies para aislar el tráfico de base de datos. Solo los pods de la aplicación deben poder hablar con PostgreSQL. Considere también la encriptación TLS para conexiones dentro del clúster.
Backup y recuperación. Aunque CloudNativePG maneja backups continuos, pruebe la restauración regularmente. Un backup que no se puede restaurar no es un backup.
Nuestro servicio de administración de bases de datos incluye exactamente este tipo de diseño y validación para clústeres PostgreSQL en AKS.
El factor costo
Uno de los argumentos más fuertes para PostgreSQL en AKS es el control de costos a escala. Con el servicio administrado, el precio está definido por la combinación de vCPUs, memoria y almacenamiento que seleccione. Con AKS, usted controla el costo del nodo (la VM), el almacenamiento (Premium SSD v2 facturado por IOPS/throughput reales) y puede compartir el clúster de Kubernetes con otras cargas de trabajo.
Para organizaciones que ya pagan por un clúster AKS para sus aplicaciones, agregar PostgreSQL al mismo clúster con nodos dedicados puede representar un ahorro significativo comparado con un servicio administrado separado.
El trade-off es operacional: usted asume la responsabilidad de las actualizaciones del operador, la gestión de certificados TLS y el monitoreo proactivo. Pero con CloudNativePG y las herramientas de Azure, ese trabajo operacional es manejable para un equipo con experiencia en Kubernetes.
Lo que esto significa para empresas en la región
PostgreSQL es la base de datos preferida para aplicaciones modernas en América Latina. Es open-source, tiene un ecosistema maduro y no tiene costos de licenciamiento. Ejecutarla en AKS es la evolución natural para organizaciones que ya están invirtiendo en contenedores y en la plataforma Azure.
Si su empresa está planeando una migración a la nube o modernizando su infraestructura de bases de datos, PostgreSQL en AKS es una opción que debe estar en la conversación.
No porque sea la respuesta para todos los casos — sino porque para los casos correctos, ofrece una combinación de rendimiento, flexibilidad y control de costos que el servicio administrado simplemente no puede igualar.
Preguntas frecuentes
¿Es seguro ejecutar bases de datos de producción en Kubernetes?
Sí, con la arquitectura correcta. Kubernetes ha madurado significativamente para cargas con estado. CloudNativePG proporciona failover automático, replicación y backups continuos. La clave es usar nodos dedicados, almacenamiento Premium SSD y probar la recuperación ante fallos regularmente. Organizaciones como GitLab y Bloomberg ejecutan PostgreSQL en Kubernetes en producción a gran escala.
¿Cuánto puedo ahorrar usando PostgreSQL en AKS en lugar del servicio administrado?
El ahorro depende de la escala. Para instancias pequeñas (2-4 vCPUs), el servicio administrado suele ser más económico por la simplicidad operacional. Para cargas de trabajo grandes o múltiples instancias de PostgreSQL, ejecutar en AKS puede reducir costos entre un 30% y 50%, especialmente si ya tiene un clúster AKS para otras aplicaciones y puede compartir la infraestructura base.
¿Qué nivel de experiencia necesita mi equipo para operar PostgreSQL en AKS?
Su equipo necesita experiencia práctica con Kubernetes (deployments, StatefulSets, almacenamiento persistente) y conocimiento operacional de PostgreSQL (replicación, tuning, backup/restore). CloudNativePG simplifica muchas tareas, pero no elimina la necesidad de entender ambas tecnologías. Si su equipo no tiene esta experiencia internamente, un servicio de consultoría tecnológica puede acelerar la implementación inicial y transferir conocimiento.