The best platforms for running PostgreSQL in containers fall into three main groups: Kubernetes with a Postgres operator, managed platforms that run Postgres in containers for you, and managed database services paired with containerized apps. HashiCorp Nomad, a general-purpose orchestrator, is also covered. The key differences are who operates the Kubernetes cluster and storage, how failover works, and whether the database can span regions. The comparison matrix in this guide shows, for all 11 options, which operational tasks your team owns and which the platform handles. Control Plane fits in the second group: it runs Postgres from templates in its Template Catalog, a library of ready-to-install apps, on AWS, GCP, Azure, and Oracle Cloud without requiring you to operate a Kubernetes cluster.
Disclosure: Control Plane publishes this guide.
TL;DR
The best platform for running Postgres in containers depends on how much of the stack you want to own.
- Managed platforms that run Postgres in containers for you. Control Plane runs Postgres templates (single-instance, highly available, multi-location, and active-active pgEdge) on its stateful workload type. Each replica gets its own persistent volume, the highly available and multi-location templates add Patroni failover, and you never have to operate a Kubernetes cluster.
- Kubernetes with a Postgres operator. CloudNativePG, Crunchy Postgres for Kubernetes (PGO), Zalando Postgres Operator, StackGres, Percona Operator for PostgreSQL, and Red Hat OpenShift with a certified operator automate Postgres lifecycle tasks. Your team operates the Kubernetes cluster, storage, and networking.
- Managed database services paired with containerized apps. Amazon RDS or Aurora, Google Cloud SQL or AlloyDB, and Azure Database for PostgreSQL Flexible Server run Postgres for you while your containers connect over the network. The provider runs failover, backups, and patching; your team schedules and tests major-version upgrades.
- Replication mode matters. Postgres streaming replication is asynchronous by default, so a failover can lose the most recent transactions. Check which mode each option uses and monitor replication lag.
How the 11 options compare on failover, backups, and multi-region
The table compares 11 options on who operates the cluster, how failover works, how backups and point-in-time recovery (PITR) are handled, and whether Postgres can span regions.
| Option | Group | Who operates the Kubernetes cluster | How failover works | Backups and point-in-time recovery | Multi-region option |
|---|---|---|---|---|---|
| Control Plane (Template Catalog Postgres templates) | Managed platform | Control Plane, on Control Plane-managed locations. You never have to operate a Kubernetes cluster. Control Plane Managed Kubernetes (MK8s) and Bring Your Own Kubernetes (BYOK) are available if you want your own clusters. | Highly available template: Patroni promotes the most up-to-date replica and HAProxy moves port 5432 to the new leader. Open connections are reset, so apps should retry with backoff. | The single-instance, highly available, and multi-location templates offer optional scheduled pg_dumpall backups to S3, GCS, or MinIO, and the pgEdge template offers optional scheduled pg_dump backups to S3 or GCS. The highly available and multi-location templates add optional WAL-G continuous WAL archiving and base backups; WAL-G restores are a manual procedure into an empty data directory, which the template docs advise rehearsing. Volume sets (Control Plane’s managed persistent storage) support scheduled snapshots with a retention period. | Yes. The multi-location template runs one primary with asynchronous replicas across locations in a Global Virtual Cloud (GVC), Control Plane’s named set of locations across one or more clouds, with automatic failover at three or more locations. The pgEdge template runs active-active multi-master Postgres across locations. |
| CloudNativePG on EKS, GKE, or AKS | Kubernetes operator | Customer operates or pays for a managed Kubernetes service. | The operator detects the failed primary through its readiness probe. A Kubernetes Lease-backed leader election promotes a ready replica. | Backup to S3, Azure Blob, or GCS via the Barman Cloud Plugin; supports PITR via WAL archiving. | Cross-Kubernetes-cluster replication (distributed topology) via the replica cluster feature. |
| Crunchy Postgres for Kubernetes (PGO) | Kubernetes operator | Customer operates or pays for a managed Kubernetes service. | Patroni-based failover with leader election. | pgBackRest to S3, GCS, or Azure Blob with PITR. | Standby cluster in another Kubernetes cluster via a shared pgBackRest repo or streaming replication. Promotion is manual. |
| Zalando Postgres Operator | Kubernetes operator | Customer operates or pays for a managed Kubernetes service. | Patroni-based failover with etcd or the Kubernetes API for leader election. | WAL-G for continuous archiving. PITR available when WAL archiving is configured. | Standby cluster in another location, replicating from an S3 or GCS WAL archive or a remote primary. Promotion is manual. |
| StackGres | Kubernetes operator | Customer operates or pays for a managed Kubernetes service. | Patroni-based failover with automatic replica promotion. | Backup to S3, GCS, Azure Blob, or S3-compatible storage via built-in backup configuration. PITR supported. | Standby cluster on a separate Kubernetes cluster via SGCluster replicateFrom. |
| Percona Operator for PostgreSQL | Kubernetes operator | Customer operates or pays for a managed Kubernetes service. | Patroni-based failover with automatic leader election. | pgBackRest to S3, GCS, or Azure Blob with PITR. | Standby cluster for disaster recovery, from a pgBackRest repo or streaming replication. |
| Red Hat OpenShift with a certified Postgres operator | Kubernetes operator | Customer or Red Hat (managed OpenShift) operates the cluster. | Depends on the operator (Crunchy PGO and EDB’s certified distribution of CloudNativePG are both in the certified catalog). | Depends on the operator. | Depends on the operator and OpenShift topology. |
| HashiCorp Nomad with CSI volumes | Other orchestrator | Customer operates the Nomad cluster and CSI plugin. | No built-in Postgres failover. Requires external tooling such as Patroni with Consul as its DCS. | Customer configures backup tooling. | Customer-built; Nomad federates regions but does not replicate Postgres. |
| Amazon RDS or Aurora PostgreSQL with containers on ECS or EKS | Managed database service | AWS operates the database. Customer operates ECS tasks or the EKS cluster for the app. | RDS Multi-AZ: automatic failover to a synchronous standby. Aurora: promotes one of up to 15 read replicas on shared distributed storage. | Automated backups and continuous PITR. | RDS supports cross-region read replicas, and Aurora Global Database supports cross-region replication. |
| Google Cloud SQL or AlloyDB with containers on GKE or Cloud Run | Managed database service | Google operates the database. Customer operates the GKE cluster or Cloud Run service for the app. | Cloud SQL: regional HA with automatic failover. AlloyDB: integrated HA. | Automated backups with PITR. | Cloud SQL supports cross-region read replicas. AlloyDB supports cross-region secondary clusters. |
| Azure Database for PostgreSQL Flexible Server with containers on AKS or Azure Container Apps | Managed database service | Microsoft operates the database. Customer operates AKS or Container Apps for the app. | Optional zone-redundant or same-zone HA with automatic failover. | Automated backups with PITR. | Read replicas across regions. |
Should you run Postgres in containers at all?
Postgres needs specific things from its infrastructure, and some teams are better served by a managed database service.
What Postgres needs from infrastructure
- Durable block storage with reliable fsync. Every committed transaction must survive a power loss. The volume backing Postgres must honor fsync and fdatasync calls.
- Stable identity per replica. Each Postgres instance needs a fixed hostname and persistent volume so it can rejoin the cluster after a restart without a full resync.
- Ordered failover. When the primary fails, the most up-to-date replica must be promoted. With asynchronous streaming replication, the Postgres default, transactions no replica has received are lost on failover; synchronous replication closes that gap at the cost of write latency.
- WAL archiving for point-in-time recovery. Write-ahead log segments should be shipped to object storage continuously so the database can be restored to any point within the retention window, up to the last archived WAL segment.
- Connection pooling. Postgres forks a process per connection. A pooler such as PgBouncer multiplexes thousands of application connections into a smaller number of backend connections.
- Monitoring of replication lag. Replication lag bounds how much data a failover can lose, so measure it and alert on it.
When a managed database service is the better choice
Teams that want the provider to handle Postgres patching, backups, and failover should use RDS, Cloud SQL, or Azure Database for PostgreSQL, which include integrated monitoring, automated backups, and PITR. The trade-off is reduced portability and, in some cases, higher cost at scale.
When containers win
Running Postgres in containers makes sense when you need portability across clouds, a single deployment model for both app and database, data residency controls that require specific locations, cost control through right-sized compute, or Postgres across multiple regions from one definition. Teams pursuing active-active or active-passive architectures often benefit from containerized Postgres because the same deployment artifact works in every region.
What makes a container platform good for Postgres?
Use this checklist to evaluate any platform before committing production Postgres to it.
| Requirement | Why it matters | What to check |
|---|---|---|
| Per-replica persistent volumes | Each Postgres instance needs its own durable volume that survives restarts. | Does the platform provision a unique volume per replica? |
| Volume snapshots | Snapshots enable fast backup and cloning for dev and test. | Are scheduled snapshots supported with configurable retention? |
| Volume growth | Databases grow. Resizing a volume without downtime prevents emergencies. | Can volumes grow automatically or on demand without unmounting? |
| Failover automation | Unattended failover keeps the database available when the primary crashes. | Is failover automatic? How is the most up-to-date replica identified? |
| Backups to object storage with PITR | Object storage backups protect against volume loss. PITR protects against bad queries. | Does the platform or operator ship WAL segments and base backups to S3, GCS, or Azure Blob? |
| Connection pooling | Postgres cannot handle thousands of direct connections efficiently. | Is PgBouncer or an equivalent included or easy to add? |
| Zone spread | Spreading replicas across availability zones protects against zone failures. | Can replicas be spread across zones? |
| Multi-region replication | Regional failures and data residency requirements need cross-region capability. | Can Postgres replicate across regions, and is promotion automatic or manual? |
| Upgrade handling | Major Postgres version upgrades require careful sequencing. | Does the platform provide upgrade tooling, or is it fully manual? |
Managed platforms that run Postgres in containers for you
These platforms run Postgres containers, storage, and failover tooling on infrastructure the vendor operates. This section covers platforms that run Postgres across regions, clouds, or your own infrastructure; single-cloud developer PaaS database add-ons are out of scope.
Control Plane
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds. A stateful workload gives each replica a stable identity and its own persistent volume. A volume set provisions a unique volume for each replica and does not replicate data between volumes, so Postgres replicates at the database level through streaming replication. Volume sets have a configurable performance class, support scheduled snapshots with a retention period, can grow automatically when free space drops below a threshold, and are encrypted by default. On AWS locations, a volume set can use your own AWS KMS key per region.
The Template Catalog includes four core Postgres templates, plus PostGIS, pgvector, TimescaleDB (single-instance and highly available), and Supabase variants:
- Single-instance Postgres. One server on one volume, with optional PgBouncer pooling and optional scheduled backups to object storage.
- Highly available Postgres. Three Patroni-managed replicas coordinated by etcd in one location, with HAProxy routing port 5432 to the leader, optional PgBouncer, and optional multi-zone spread across availability zones. When the leader stops answering, Patroni promotes the most up-to-date replica.
- Multi-location Postgres. One Patroni cluster whose members span two or more locations you list in a GVC. One primary takes writes and asynchronous streaming replicas run in the other locations. With three or more locations, Patroni promotes a replica in a surviving location automatically and every location’s proxy re-routes to it. With two locations, promotion is manual. Locations can be Control Plane-managed regions or your own clusters and servers.
- pgEdge. Active-active Postgres with multi-master replication across the locations you list, so every location accepts writes. Conflicts resolve last-update-wins by commit timestamp, and DDL must be applied on each node.
The catalog also includes CockroachDB, which needs at least three locations to survive the loss of one.
On Control Plane-managed locations there is no Kubernetes cluster for you to operate. Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.
Strengths. Postgres runs alongside your application workloads from one definition, in one region or across regions and clouds from a single GVC. Multi-writer Postgres across clouds is available through pgEdge. You pay for the CPU and memory a workload reserves, with no contracts or minimums. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.
Trade-offs. Control Plane runs Postgres for you from templates; query tuning and Postgres version upgrades stay with your team, as they do with Kubernetes Postgres operators. Teams that already run Kubernetes can attach those clusters to Control Plane through BYOK or use an operator such as CloudNativePG directly. Platforms beyond Kubernetes are compared in best Kubernetes alternatives.
Who it fits. Teams that want production Postgres in containers next to their applications, on one cloud or several, without operating a cluster.
Kubernetes with a Postgres operator
Running Postgres on Kubernetes gives you portability and a unified deployment model, but your team is responsible for the cluster, storage classes, networking, and disaster recovery.
CloudNativePG
CloudNativePG is a CNCF Incubating project that manages failover through the Kubernetes API without Patroni. It handles replica promotion, continuous backup through the Barman Cloud Plugin, PITR, volume snapshot backups for fast cloning, and replica clusters for cross-cluster disaster recovery.
Strengths. Kubernetes-native design. Active CNCF community. No dependency on external consensus stores.
Trade-offs. Your team operates the Kubernetes cluster, storage, and monitoring. Multi-region means configuring replica clusters and the object store or network path between Kubernetes clusters.
Who it fits. Platform engineering teams with Kubernetes expertise who want a community-driven operator.
Crunchy Postgres for Kubernetes (PGO)
Crunchy PGO is an operator from Crunchy Data (now part of Snowflake) that uses Patroni for HA and pgBackRest for backups, and manages replica creation, failover, backups, and major-version upgrades through a declarative CRD.
Strengths. Mature pgBackRest integration. Commercial support available. Well-documented upgrade workflows.
Trade-offs. Requires Kubernetes operational maturity. Multi-region uses standby clusters fed by a shared pgBackRest repo or streaming replication, with manual promotion. The source code is Apache 2.0, but container images downloaded from the Crunchy Data Developer Portal are subject to the Crunchy Data Developer Program terms.
Who it fits. Teams that want strong backup tooling and the option of commercial support from a Postgres-focused vendor.
Zalando Postgres Operator
The Zalando Postgres Operator was built for Zalando’s internal platform and open-sourced. It packages Postgres in the Spilo container image, which bundles Patroni with WAL-G. The operator can add a separate PgBouncer connection pooler. Failover is Patroni-based with leader election through the Kubernetes API or etcd.
Strengths. Runs Zalando’s own production databases. Spilo includes WAL archiving out of the box, and the operator deploys a PgBouncer pooler on request.
Trade-offs. Tightly coupled to the Spilo image. Zalando does not make regular Spilo releases or publish latest images, and recommends building them from source.
Who it fits. Organizations already familiar with Patroni and Spilo.
StackGres
StackGres packages Postgres with connection pooling, Prometheus metrics integration with Grafana dashboards, Patroni failover, and backups into one operator with a web console.
Strengths. Built-in observability integration. Web UI for operations.
Trade-offs. Opinionated, bundled stack. Cross-cluster disaster recovery uses a standby cluster you configure with replicateFrom.
Who it fits. Teams that want an all-in-one Postgres platform on Kubernetes without assembling separate monitoring and pooling components.
Percona Operator for PostgreSQL
The Percona Operator uses Patroni for HA and pgBackRest for backups, and integrates with Percona Monitoring and Management (PMM) for observability.
Strengths. Backed by Percona’s database expertise. PMM provides query-level monitoring.
Trade-offs. Smaller community than CloudNativePG or PGO.
Who it fits. Teams already using Percona tools for MySQL or MongoDB who want a consistent operator experience for Postgres.
Red Hat OpenShift with a certified Postgres operator
OpenShift provides a certified operator catalog that includes Crunchy PGO and EDB’s certified distribution of CloudNativePG. Running Postgres on OpenShift combines the platform’s security model (role-based access, security context constraints, an integrated image registry) with the Postgres lifecycle management of the chosen operator.
Strengths. Enterprise support from Red Hat. Certified operators tested against OpenShift releases.
Trade-offs. OpenShift licensing cost. Postgres capabilities depend on the operator you select.
Who it fits. Enterprises already standardized on OpenShift that need certified, supported Postgres deployments.
Other orchestrators: HashiCorp Nomad with CSI volumes
Nomad can run Postgres containers with persistent storage through CSI volume plugins. Nomad does not include a Postgres operator, so failover must be handled externally using Patroni (with Consul as its DCS) or custom scripting. Backups are the customer’s responsibility.
Strengths. Simpler architecture than Kubernetes. Good fit for teams already invested in the HashiCorp ecosystem.
Trade-offs. No built-in Postgres automation. Smaller ecosystem of database tooling than Kubernetes.
Who it fits. Teams already on Nomad that can build their own database automation.
Managed database services paired with containerized apps
These options separate the database from the container platform. The cloud provider runs Postgres as a managed service, and your containerized application connects to it over the network.
Amazon RDS and Aurora PostgreSQL
Amazon RDS provides Multi-AZ deployments with automatic failover to a synchronous standby. Aurora PostgreSQL uses a distributed storage layer with up to 15 read replicas and Aurora Global Database for cross-region replication. Your containerized apps run on ECS or EKS and connect to the database endpoint.
Strengths. Deep AWS integration. Aurora’s shared storage layer supports fast failover.
Trade-offs. Locked to AWS. Aurora pricing is higher than standard RDS. Cross-cloud portability requires re-architecting.
Who it fits. AWS-centric teams that want the provider to run database operations.
Google Cloud SQL and AlloyDB
Cloud SQL for PostgreSQL offers regional HA with automatic failover, automated backups, and PITR. AlloyDB adds a disaggregated storage architecture for higher performance. Containerized apps on GKE or Cloud Run connect through the Cloud SQL Auth Proxy or a private IP.
Strengths. Tight GCP integration. AlloyDB offers strong analytical query performance alongside OLTP.
Trade-offs. Locked to GCP.
Who it fits. GCP-focused teams wanting managed Postgres with minimal operational overhead.
Azure Database for PostgreSQL Flexible Server
Azure Database for PostgreSQL Flexible Server is reached from containerized apps on AKS or Azure Container Apps through private access (virtual network integration) or private endpoints.
Strengths. Native Azure networking integration. Flexible compute scaling. Optional zone-redundant or same-zone HA.
Trade-offs. Locked to Azure. Feature parity with RDS and Cloud SQL varies by capability.
Who it fits. Azure-first organizations that want managed Postgres alongside containerized workloads.
How do I choose a platform for Postgres in containers?
| If you need | Consider | Why |
|---|---|---|
| Postgres next to your app with no cluster to run | Control Plane | Stateful workloads with volume sets and Postgres templates, in one region or many, with no Kubernetes cluster to operate. |
| You already run Kubernetes and have platform engineers | CloudNativePG, Crunchy PGO, or Zalando Operator | Operators automate Postgres on your existing clusters. Your team controls the full stack. |
| Enterprise support on OpenShift | Red Hat OpenShift with Crunchy PGO or CloudNativePG | Certified operators with Red Hat support contracts. |
| Least database operations work on one cloud | RDS/Aurora, Cloud SQL/AlloyDB, or Azure Database for PostgreSQL | The cloud provider runs failover, backups, and patching. |
| Postgres across regions or clouds | Control Plane (multi-location or pgEdge template), Aurora Global Database, or cross-region replicas on Cloud SQL, AlloyDB, or Azure Database for PostgreSQL | Control Plane spans AWS, GCP, Azure, and Oracle Cloud from one definition, and pgEdge on Control Plane accepts writes in every location. Multi-cloud failover options are compared in best multi-cloud failover solutions. Aurora Global Database spans AWS regions. |
| On-premises or data residency | Control Plane (BYOK or Managed Kubernetes locations) or any Kubernetes operator on your own clusters | Control Plane runs workloads on your own clusters and servers, including on premises. Operators run wherever Kubernetes runs. |
| Other stateful databases alongside Postgres | Control Plane | The Template Catalog includes CockroachDB, pgEdge, TiDB, Cassandra, MongoDB, MySQL, MariaDB, Redis, and Neo4j templates. |
FAQ
Short answers to common questions about running Postgres in containers.
What are the best platforms for running stateful workloads like Postgres in containers?
The three main groups are managed container platforms such as Control Plane, Kubernetes operators such as CloudNativePG and Crunchy PGO on clusters you operate, and managed database services such as Amazon RDS, Google Cloud SQL, and Azure Database for PostgreSQL. The right choice depends on how much operational responsibility your team can absorb.
Is it safe to run Postgres in containers in production?
Yes, when the platform provides volumes that honor fsync, a stable identity per replica, automated failover, and continuous WAL archiving. The main production risks are misconfigured storage and missing failover automation.
Is it better to run Postgres on Kubernetes or use a managed database?
A Kubernetes operator gives you portability and one deployment model for app and database, and suits teams with platform engineers. A managed database service means less operational work because the provider runs failover, backups, and patching on a single cloud.
What is the best Kubernetes operator for Postgres?
CloudNativePG, Crunchy PGO, and Zalando Postgres Operator are the three most-starred on GitHub. CloudNativePG is Kubernetes-native and a CNCF Incubating project, Crunchy PGO has mature pgBackRest integration and commercial support, and Zalando bundles Patroni and WAL-G in its Spilo image. StackGres adds built-in observability integration and Percona integrates with PMM.
How does Postgres failover work in containers?
Patroni-based operators and Control Plane’s highly available template promote the most up-to-date replica and route traffic to it through a proxy or Kubernetes service; CloudNativePG does the same through the Kubernetes API. With asynchronous replication, transactions no replica received are lost. Applications should reconnect with retry and backoff.
How do I back up Postgres running in containers?
Combine base backups with continuous WAL archiving to S3, GCS, or Azure Blob using pgBackRest, Barman Cloud, or WAL-G, and test restores regularly. On Control Plane, every Postgres template supports optional scheduled backups to object storage, the highly available and multi-location templates can also archive WAL continuously with WAL-G, and volume sets support scheduled snapshots.
Can I run Postgres across multiple regions in containers?
Yes. Control Plane’s multi-location template runs one primary with asynchronous replicas across GVC locations on AWS, GCP, Azure, and Oracle Cloud, with automatic failover at three or more locations, and its pgEdge template accepts writes in every location. Aurora Global Database replicates across AWS regions, and CloudNativePG, Crunchy PGO, Zalando, StackGres, and Percona support standby or replica clusters in another Kubernetes cluster. Monitor replication lag, which bounds data loss on a regional failover.
How does Control Plane run Postgres?
Control Plane runs Postgres as a stateful workload, where each replica gets a stable identity and its own volume from a volume set. The Template Catalog provides single-instance, highly available, multi-location, and pgEdge templates, and on Control Plane-managed locations there is no Kubernetes cluster for you to operate.
Does Control Plane support other stateful databases besides Postgres?
Yes. The Template Catalog includes distributed databases such as CockroachDB, pgEdge, TiDB, and Cassandra, plus MongoDB, MySQL, MariaDB, Redis, and Neo4j templates. Any containerized database that needs persistent storage can use the stateful workload type with volume sets.
What storage considerations matter most for Postgres in containers?
Each replica needs its own persistent volume that honors fsync and survives restarts and rescheduling. Snapshots speed up backup and cloning, and automatic growth prevents disk-full outages; Control Plane volume sets provide a volume per replica, scheduled snapshots, and automatic growth, with encryption by default.
To run Postgres in containers without operating a Kubernetes cluster, talk to the Control Plane team or sign up free.
