postgres-containers on UBI image

[Ramki33]

HI ,
Good Day ,

In our product we want to use postgres-containers on UBI image .

Any idea why CNPG is providing postgres-containers on UBI image ?

If we build postgres-containers on UBI image will it work, any issue or blocker will be there .

Can some one help here & clarify . Thanks

[dosubot]

Hi @Ramki33! I'm Dosu and I’m helping the postgres-containers team.

Hi, I can help clarify the UBI situation for postgres-containers.

Current Status: CloudNativePG does not provide postgres-containers on UBI images. All PostgreSQL operand images are built exclusively on Debian Linux (Trixie, Bookworm, or Bullseye slim variants).

However, the operator (cloudnative-pg) does have UBI9 support, primarily intended for OLM deployment on OpenShift.

Will building on UBI work? There are no documented technical blockers preventing you from building postgres-containers on UBI. The lack of UBI support appears to be a strategic architectural decision rather than a technical limitation. The project has explicitly committed to Debian as the standard base for Kubernetes-native container design.

Potential considerations if you build your own UBI-based images:

• You'd need to adapt the Dockerfiles and package installation for RPM-based distributions
• You'll be responsible for maintaining and testing these custom images
• Ensure compatibility with CloudNativePG's expectations for the operand container

If UBI support for postgres-containers is important for your product, you might consider opening a feature request to gauge community interest and discuss potential official support.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Ramki33]

HI @dosu,

Is base image is very important , what kind of problem we see when change Base image to UBI .
what support we miss from CNPG

[dosubot]

Hi,

Here are the key challenges you'd face when changing the base image to UBI, and what support you'd lose from CNPG:

Technical Problems with UBI:

1. Package management differences - The current Dockerfiles use APT and Debian packages. Packages like postgresql-common (Debian's PostgreSQL configuration framework) don't exist on RHEL. You'd need to find or build RPM equivalents.

2. PostgreSQL binary paths - Debian uses /usr/lib/postgresql/$PG_MAJOR/bin, while RHEL typically uses /usr/pgsql-${VERSION}/bin. The operator expects certain executables in PATH: initdb, postgres, pg_ctl, pg_controldata, pg_basebackup, pg_rewind, pg_isready.

3. Extensions availability - The standard images include pgaudit, pgvector, and pg-failover-slots as Debian packages. You'd need to find or compile equivalent RPM packages.

4. User requirements - The postgres user (UID 26) must exist at build time - runtime user creation is not supported.

What CNPG Support You'd Miss:

• No official support - UBI images would be entirely community-unsupported
• No automated security updates - Official images get weekly rebuilds with scanning
• No compatibility testing - No validation against operator releases
• No community bug fixes - Issues would be your responsibility

Good News: CloudNativePG's container requirements are relatively minimal. If you ensure the right PostgreSQL executables are in PATH, use the expected directory structure (/var/lib/postgresql/data/pgdata), and create the postgres user at build time, a UBI-based image can work - you'd just own the maintenance burden.

Would you consider running the official Debian-based images on your RHEL/OpenShift hosts? That's a supported pattern that avoids these complexities.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}