Quick take

Bitnami's free Postgres Helm chart is effectively dead in 2026. Broadcom moved tagged images behind a paywall in September 2025. The production-grade replacement is CloudNativePG, a CNCF Postgres operator with streaming replication, point-in-time recovery, and automatic failover. Here is the setup that actually runs in prod, every block explained.

If you only have 90 seconds, this is the shape:

• Bitnami is over for new free deployments. Migrate or pay.
• CloudNativePG (CNPG) is the new default and is genuinely operator-grade.
• The four things you must get right: storage class, backup target, replica count, and pooler.

Why 2026 changed the Postgres-on-K8s playbook

Three things shifted in the last twelve months and almost every existing tutorial is now wrong.

Bitnami went paywalled. Broadcom took ownership of Bitnami after the VMware acquisition and moved all tagged Postgres images behind a Tanzu subscription in September 2025. The Helm chart still exists, but the images it points to are no longer free. Teams running bitnami/postgresql:15.4.0-debian-12-r0 on a fresh cluster get a registry auth error.

CloudNativePG hit GA at the CNCF. CNPG was incubated through 2024 and is now the de facto Postgres operator on Kubernetes. It handles streaming replication, automatic failover, backup, and point-in-time recovery without you stitching scripts.

FOCUS and FinOps changed the cost story. Postgres on K8s used to lose on price to managed RDS for small workloads. With Karpenter, gp3 storage at $0.08/GB-month, and CNPG's bin-packing, the break-even shifted. For most teams above ~$300/month of RDS spend, CNPG is cheaper.

The upshot is that the question is no longer "Bitnami or Crunchy" but "operator or managed service."

Operator versus chart: pick one before you start

The wrong choice here costs a week of rework. Here is the rule I use.

If your environment crosses the line from "throwaway" to "actually serves users," the operator path is the only one that ages well. The rest of this post assumes CNPG.

A production CNPG setup at a glance

Here is the values map that actually deploys cleanly on a fresh cluster today. Every row is load-bearing.

That is the production minimum. Nine settings, each load-bearing.

Replication and high availability

CNPG runs streaming replication out of the box. Three instances is the sweet spot: one primary, two synchronous standbys. With three you survive the loss of any single node without committing reads or writes against unverified data.

Synchronous versus async replication

• Synchronous (synchronous.method: any) waits for at least one standby to ack the write. Slight latency cost, zero data loss on failover.
• Asynchronous is the default and is fine for most teams. Failover can lose the last 1 to 5 seconds of writes.

The trade-off is real. I use synchronous for payment, ledger, and audit databases. Async for everything else.

Failover behavior

CNPG promotes a standby in 5 to 30 seconds when the primary fails. The application sees a brief connection error and needs to reconnect. If your client library does not retry on connection loss, you will see user-visible errors during failover. The Pooler resource fronts this with PgBouncer, which is the next section.

Backups and point-in-time recovery

The number-one mistake I see is teams running CNPG without a configured backup target. The operator does not back up by default. You explicitly create a Backup and ScheduledBackup resource.

What to configure

• Object storage target (S3, GCS, Azure Blob) with a barmanObjectStore block.
• Backup schedule running daily at low-traffic hours, retention of 7 to 30 days.
• WAL archiving enabled, which is required for point-in-time recovery to work.
• Retention policy that survives accidental cluster deletion. Use object storage lifecycle rules, not just CNPG retention.

Test the restore. An untested backup is a wish, not a backup. Quarterly restore drill to a sandbox cluster is the bar.

Observability and connection pooling

CNPG ships a Postgres exporter built into the operator. Enable monitoring.enablePodMonitor: true and you get pgsql_up, replication lag, transaction counts, and slow query metrics scraped by Prometheus automatically.

The connection pooler is more subtle. Use PgBouncer in transaction mode. CNPG provisions it as a separate Pooler CR pointing at your Cluster. Set default_pool_size: 25 for most workloads, higher only if you have measured contention. More is not better here.

Without pooling, every Lambda or pod opens a fresh Postgres connection. Connection storms during traffic spikes are the second most common Postgres-on-K8s incident I get pulled into.

The four pitfalls that wreck a fresh CNPG install

Every incident I have helped debug has been one of these.

1. The "we will configure backups later" trap

CNPG looks healthy without a backup config. The dashboards stay green. Then someone runs a bad DELETE, and the team learns that "later" never happened. Configure the backup target on day one.

2. The missing WAL storage

Putting WAL on the main data PVC means a write burst can fill the disk and stop the primary. Always create a separate walStorage PVC of at least 20Gi. Operator default is to skip this, which is the operator's only real footgun.

3. The under-sized pooler

Defaulting PgBouncer to 10 connections looks safe but causes lock contention under load. 25 default plus 10 reserve is the floor I use for any production cluster.

4. The mismatched Postgres version on restore

Restoring a backup from Postgres 15 to a cluster running 16 sometimes works and sometimes silently corrupts the database. Pin major versions and only upgrade via CNPG's documented major-version path.

Where this setup still falls short

This is the honest part.

Cross-region disaster recovery is not built in. CNPG can run a "distributed" cluster across regions but the network and storage cost makes it expensive. Most teams ship WAL archives to a second region and restore on demand.

Logical replication for zero-downtime upgrades still needs manual orchestration. CNPG 1.24 added some helpers, but anything more complex than a minor version bump is a project.

Connection multiplexing across nodes is single-pooler. For 10,000+ concurrent clients you need a layer in front of the pooler too. RDS Proxy has no CNPG equivalent that is as mature.

Frequently asked questions

Can I migrate from Bitnami to CNPG without downtime?
Mostly yes. Use logical replication from the Bitnami primary to a new CNPG cluster, then cut over with a brief read-only window. The CNPG docs have a migration guide.

Does CNPG support PgVector?
Yes. Use a CNPG-compatible image that includes the extension, like ghcr.io/cloudnative-pg/postgresql:16.4-pgvector. The operator does not care about extensions, only the underlying Postgres binary.

How much memory should a production primary get?
Rule of thumb: shared_buffers at 25% of memory, work_mem at 4 to 16MB per connection. A 4Gi pod fits a small workload. Anything serving real traffic should be 8Gi minimum.

Is CNPG ready for OLTP at scale?
Yes. There are public references of CNPG running multi-TB clusters at 50k QPS. The bottleneck in 2026 is almost always your storage class throughput, not the operator.

Should I run Patroni instead?
Patroni works and is mature, but you operate it yourself. CNPG hides the same primitives behind a friendlier abstraction. Unless you have an existing Patroni investment, CNPG is the lower-effort choice.

What is your current Postgres setup?

If you are still on Bitnami in 2026, the question is whether you are paying for Tanzu or paying in incidents. If you have moved to CNPG, what tripped you up first? Drop your stack in the comments. I read every one and reply with what I would have set differently.