Bitnami PostgreSQL to CloudNativePG: choose an import and prove recovery

Replacing a Bitnami PostgreSQL deployment means moving a working database, including its data, users and application connections. A new chart or image starting successfully does not show that it contains the right data or that your applications can use it.

PostgreSQL is the database. Bitnami supplies one way to package and deploy it. CloudNativePG is a Kubernetes operator: a controller that manages PostgreSQL clusters and helps automate tasks such as replacing instances and coordinating their configuration. Moving to it changes database administration as well as packaging.

Choose CloudNativePG when you want to run PostgreSQL inside Kubernetes and can maintain the operator and its backup system. Consider a managed database when transferring more of that work to a provider is preferable. This guide explains a move to CloudNativePG, then presents the separately recorded PostgreSQL restore experiment with its exact limits.

Record the data and database features you must preserve

Record PostgreSQL major/minor versions, extensions, databases, roles, ownership, encodings, locale/collation, replication, authentication and client connection settings. Measure actual dataset size and write rate. Include scheduled jobs, exporters and applications that use administrative credentials.

Select a transfer method

A logical export/import can separate storage layouts and deployment packaging, but takes time and requires role/extension planning. Replication can reduce interruption where the source and target support the chosen method, but introduces synchronization and cutover complexity. Use the target's release-specific import documentation; do not assume physical files are portable between arbitrary images or versions.

1. Restore a recent copy into an isolated target and confirm all required extensions are available.
2. Run application queries, ownership checks, sequence checks and representative transactions.
3. Create a fresh backup using the target's intended backup system and prove that it restores independently.
4. Rehearse the final transfer, record downtime and lag, then decide when writes will stop or switch.
5. Change application credentials and endpoints through a controlled rollout; observe errors and connection saturation.

Choose the CloudNativePG import behavior

CloudNativePG 1.30's database import bootstraps a new cluster. The microservice mode imports one database into the chosen application database and owner, without importing source roles or preserving source ownership and ACLs. Use it when that simplification matches the application; recreate the required grants deliberately.

The monolith mode can import selected databases and roles. It still excludes reserved roles and removes imported superuser privileges. Inventory the actual grants and administrative jobs rather than assuming that a successful import recreates every source capability. Provision application connection Secrets and TLS settings for the target.

The logical import takes a snapshot. Writes committed on the source after that snapshot are not continuously copied by this import. Stop and verify all writers before the final export, or design and rehearse a separate replication procedure. Include background workers, scheduled jobs, connection pools and administrative scripts in the write-freeze check. Allocate space for temporary dumps as well as restored data and indexes.

Record the production cutover gates

• Before the final transfer: the target has the required extensions and roles; its fresh backup restores into independent storage; the source is retained and the write-freeze mechanism has been exercised.
• Before opening writes: compare important row counts and application invariants, test sequence-generated IDs, check privileges using application credentials and validate the new endpoint through the application's real connection path.
• After opening writes: observe transactions, errors, connection saturation and backup health. The old source is now a retained recovery asset, not automatically a current database.

Set measurable gates for the application. An order service might require every pre-cutover order and payment reference to match, a new order to receive a valid ID, and a read-only user to remain unable to change data. These are rehearsal criteria, not results from a Bitnami-to-CloudNativePG deployment. The recorded Docker experiment below covers only its stated database transfer.

Decide the point of no simple return

Once the new database accepts writes, pointing applications back at the old database can lose those writes. Define a reverse-sync plan or an explicit restore-and-replay procedure before cutover. Retain the source and backups under a documented retention policy; do not let release cleanup delete the only rollback copy.

The deployment move still needs your own rehearsal. The bounded experiment below tests one logical data transfer; it does not certify a Bitnami chart conversion, CloudNativePG deployment or production cutover. See the distribution decision for the chart/image distinction.

Observed restore: PostgreSQL 16.15 to 18.6

On 9 October 2026 we ran the downloadable restore fixture using three new Docker containers on Linux arm64. Official Debian Bookworm images were pinned by digest. The target version’s pg_dump client exported the source; pg_restore used an explicit failure-on-error, single-transaction restore. No host port, Kubernetes context, existing database or real customer data was used.

The synthetic dataset contains 100 customers and 250 orders, with Unicode text, JSONB, hstore, an enum, nullable values, bytea, decimal amounts and timestamps. Identity sequences, ownership, a reader role, indexes, a view and relational constraints are part of the acceptance check. The two NOLOGIN roles are created explicitly on each server, so the test does not claim automatic role/password migration.

1. The source rejected a write after its database default was made read-only. There were no existing application connections; this setting alone is insufficient to freeze a real system’s established writers.
2. The target restored all rows with identical content fingerprints and preserved sequence positions, ownership, privileges and schema checks. A reader could query but could not delete; a foreign-key violation was rejected.
3. A fresh backup made on the new target restored into a third container with independent storage and matched the baseline. A truncated backup failed, and the single-transaction restore left no partial application tables.
4. Before committing target writes, the retained source was reopened and accepted a test transaction, which was rolled back. Its identity sequence was explicitly reset because PostgreSQL sequence advances are not rolled back with a transaction.
5. After one target-only order was committed, the target held 251 orders and the source held 250. That mismatch demonstrates why a later endpoint reversal would lose data without reconciliation.

What this evidence can support

The fixture proves a repeatable logical restore and independent target backup for this exact, small version pair and schema. It exercises a return to the original database before target writes and exposes the limit after writes. It does not test an application endpoint switch, reverse replication, a Kubernetes storage move, a Helm upgrade, HA failover or point-in-time recovery. All three containers, their temporary volumes and their internal network were removed after the run.

The complete observed results include image identities, row fingerprints and cleanup. The reproduction notes explain prerequisites and exclusions. The recorded 9.31 seconds is a cached-image local test duration, not expected production downtime. The dump hashes identify that run; reruns can differ in archive metadata while preserving the same checked data.

Use this as the shape of a rehearsal, then replace the synthetic cases with your application’s extensions, ownership rules, large objects, data volume and consistency checks. Add the target operator’s backup/restore path and an application-level switch test. Keep the old deployment until that evidence and the write-reconciliation decision are complete.