Azure Database for PostgreSQL is a solid managed service. For most teams, it is the right default. But defaults have limits — and when your workload outgrows what a managed service exposes, the question shifts from "should we use PostgreSQL" to "where should we run it."
Running PostgreSQL on Azure Kubernetes Service is not a fringe experiment. Microsoft is actively publishing reference architectures, optimized VM families, and tooling specifically for this pattern. The reason is straightforward: organizations that have already committed to Kubernetes for their application layer want a unified platform, and modern operators like CloudNativePG make self-hosted PostgreSQL on Kubernetes a production-viable option.
This article covers the architecture, the trade-offs, and the practical considerations for teams evaluating this approach.
Why PostgreSQL on Kubernetes works now
For years, the advice was simple: do not run databases on Kubernetes. The storage primitives were unreliable, operators were immature, and failover required custom scripting. That era is over.
Kubernetes now has stable primitives for stateful workloads. StatefulSets provide stable network identities and ordered deployment. Persistent Volume Claims with dynamic provisioning handle storage lifecycle. And the operator ecosystem — specifically CloudNativePG — has matured to the point where it automates the operations that previously required a dedicated DBA.
CloudNativePG is not a generic database operator. It is a CNCF project built exclusively for PostgreSQL, originally developed by EDB. It handles synchronous and asynchronous replication, automatic failover, continuous backup to object storage, rolling updates, and Prometheus-native monitoring. All of it declared in YAML and reconciled by Kubernetes.
The result: a highly available PostgreSQL cluster with read replicas, continuous WAL archiving to Azure Blob Storage, and automatic failover — managed declaratively, the same way you manage your application deployments.
What makes AKS specifically suited for database workloads
Not every Kubernetes environment is equal when the workload is a database. AKS has Azure-specific optimizations that matter for I/O-intensive, latency-sensitive workloads like PostgreSQL.
Storage-optimized VMs. Azure offers VM families like Ebdsv5 and Lsv3 designed for high I/O throughput. These include local NVMe disks with sub-millisecond latency and throughput exceeding 5 GB/s. For PostgreSQL, where I/O performance is the single biggest bottleneck, node selection has a measurable impact on query performance.
Premium SSD v2 and Ultra Disk. AKS supports storage classes that use Premium SSD v2, where you configure IOPS and throughput independently. You are not paying for a predefined performance package — you dial in exactly what your workload demands. For write-heavy production environments, Ultra Disk offers up to 160,000 IOPS per disk.
Accelerated Networking. AKS enables accelerated networking by default on compatible nodes, reducing network latency between pods. When your application and database run in the same cluster, this optimization has a direct impact on query response times.
Azure Monitor integration. CloudNativePG exposes Prometheus metrics that can feed into Azure Monitor and Azure Managed Grafana, giving you a single observability plane across your application and database layers.
CloudNativePG: the operator that makes this viable
The operator is what separates a production-grade deployment from a fragile experiment. Without a competent operator, you would be writing failover scripts and cron jobs for backups — exactly the kind of manual work Kubernetes is supposed to eliminate.
Here is what CloudNativePG handles:
- High availability. Synchronous or asynchronous replication with automatic failover. If the primary node fails, CloudNativePG promotes a replica to primary in seconds.
- Continuous backup. Native integration with Azure Blob Storage for WAL archiving and base backups. Configurable retention by time or count, with no performance impact on the running cluster.
- Rolling updates. Updating PostgreSQL versions or engine configuration is a manifest change. CloudNativePG coordinates the process replica by replica, with zero downtime.
- Declarative management. You define the desired state — three replicas, hourly backups, Premium SSD storage — and the operator maintains it. Pods are recreated if they fail. Workloads migrate if nodes go down. The operator is the automated DBA.
This declarative model is critical. It means your database infrastructure is version-controlled, auditable, and reproducible — the same principles you apply to your application code.
When to use Azure Database for PostgreSQL vs. self-hosted on AKS
This is not an either-or decision. Both options are valid, and the right choice depends on your team, your workload, and your operational constraints.
Azure Database for PostgreSQL Flexible Server is the right choice when your team wants fully delegated engine management. Security patches, high availability, backups, and monitoring are included. It is ideal for smaller teams, standard SaaS applications, and scenarios where time-to-market matters more than deep customization.
PostgreSQL on AKS makes sense when you need control over engine configuration (parameters in postgresql.conf that the managed service does not expose), when your application already runs on Kubernetes and you want a unified platform, when you need multiple PostgreSQL instances with different versions or configurations, or when managed service costs at scale become difficult to justify.
There is also a common third scenario: organizations migrating from on-premises PostgreSQL that need an intermediate step. Running on AKS lets them replicate their exact on-premises configuration while adapting the application for the cloud.
If your organization is evaluating this decision, our technology consulting team can assess your workload and recommend the architecture that best fits your performance, cost, and operational requirements.
Production considerations that matter
Running PostgreSQL on AKS is not just installing a Helm chart. There are architecture decisions that directly affect stability and performance:
Node affinity. PostgreSQL pods should run on dedicated nodes with taints and tolerations. You do not want application deployments competing for CPU and memory with your database.
Storage class. Define a StorageClass specifically for PostgreSQL that uses Premium SSD v2 or Ultra Disk. Standard storage is not acceptable for production database workloads.
Resource limits. Configure CPU and memory requests and limits conservatively. PostgreSQL needs predictable memory for shared_buffers and work_mem. If Kubernetes OOM-kills a pod, you lose the replica.
Network isolation. Use network policies to restrict database traffic. Only application pods should be able to communicate with PostgreSQL. Consider TLS encryption for intra-cluster connections as well.
Backup validation. Although CloudNativePG handles continuous backups, test your restore process regularly. A backup that cannot be restored is not a backup.
Our database administration service covers exactly this kind of design, validation, and ongoing operational support for PostgreSQL clusters on AKS.
The cost argument
One of the strongest cases for PostgreSQL on AKS is cost control at scale. With the managed service, pricing is defined by the vCPU, memory, and storage tier you select. With AKS, you control the node cost (the VM), the storage cost (Premium SSD v2 billed by actual IOPS and throughput), and you can share the Kubernetes cluster with other workloads.
For organizations already paying for an AKS cluster for their application layer, adding PostgreSQL with dedicated node pools can represent meaningful savings compared to a separate managed service instance — particularly when running multiple databases.
The trade-off is operational: you own the operator upgrades, TLS certificate management, and proactive monitoring. But with CloudNativePG and Azure-native tooling, that operational overhead is manageable for teams with Kubernetes experience.
Practical next steps
If your team is considering this architecture, here is a reasonable evaluation path:
-
Assess your current database workload. Identify whether your managed PostgreSQL instance has configuration limitations that affect your application. If the managed service works and your team is small, stay with it.
-
Evaluate your Kubernetes maturity. Running databases on Kubernetes requires operational confidence with StatefulSets, persistent storage, and monitoring. If your team is still learning Kubernetes fundamentals, this is not the right first project.
-
Start with a non-production instance. Deploy CloudNativePG on an AKS dev cluster. Test failover, backup, and restore. Measure I/O performance with your actual query patterns.
-
Plan for cloud migration holistically. If you are migrating from on-premises PostgreSQL, evaluate whether AKS or the managed service better fits your operational model long-term. The answer might be different for different databases in your portfolio.
-
Engage expertise early. The architecture decisions made during initial deployment — node selection, storage class, network design — are expensive to change later. Getting them right the first time saves months of re-work.
PostgreSQL on AKS is not the right answer for every team. But for organizations that need the combination of open-source flexibility, cloud-native operations, and fine-grained cost control, it is an architecture worth serious evaluation.
Frequently asked questions
Is it safe to run production databases on Kubernetes?
Yes, with the right architecture. Kubernetes has matured significantly for stateful workloads. CloudNativePG provides automatic failover, replication, and continuous backup. The critical requirements are dedicated node pools, Premium SSD or Ultra Disk storage, network isolation, and regular disaster recovery testing. Organizations including GitLab and Bloomberg run PostgreSQL on Kubernetes in production at significant scale.
How much can I save running PostgreSQL on AKS instead of the managed service?
Savings depend on scale. For small instances (2-4 vCPUs), the managed service is often more cost-effective due to reduced operational overhead. For large workloads or multiple PostgreSQL instances, AKS can reduce costs by 30% to 50%, especially if you already have an AKS cluster for application workloads and can share the base infrastructure. The key is modeling total cost of ownership, including the operational time your team will invest.
What expertise does my team need to operate PostgreSQL on AKS?
Your team needs hands-on experience with Kubernetes (deployments, StatefulSets, persistent storage, monitoring) and operational knowledge of PostgreSQL (replication, performance tuning, backup and restore). CloudNativePG simplifies many tasks but does not eliminate the need to understand both technologies. If your team lacks this experience internally, a technology consulting engagement can accelerate the initial deployment and transfer the operational knowledge your team needs long-term.