EDB Postgres AI on Red Hat OpenShift Virtualization: Enterprise HA Without Rewriting Your Stack

This blog was coauthored by EDB Product Marketing Manager Danny Navo.

EDB Postgres AI is tested and supported on Red Hat OpenShift Virtualization. VMs and containers run side by side on the same control plane, so teams can bring their existing VM-based Postgres onto OpenShift next to their containerized apps, without re-architecting the database to do it.

That combination matters because most enterprise Postgres^® still runs on virtual machines, and it will keep running there for years. The industry conversation has moved to containers, but the estates have not, and the database tier is the slowest part of any estate to move. EDB Postgres AI closes that gap: a validated, supported way to run VM-based Postgres on OpenShift Virtualization without re-architecting it first.

Why the database migrates last

Postgres itself containerizes fine, but the contents of VMs are more difficult to move over. Examples of things pinned to the VM rather than to Postgres include: 

• Storage layout and file system tuning that the backup retention policy was sized against
• Failover behavior and the connection routing sitting in front of it
• Third-party agents for backup, monitoring, and security that are certified against an OS on a VM, not against a container image
• Audit and compliance scope written against named hosts
• The runbook that the on-call DBA actually follows at 2 a.m.

Containerizing the database tier means revalidating all of that at once, usually while the application teams are busy with other migrations. Most platform teams will not prioritize that while they are already relocating thousands of VMs.

Platform teams are feeling this now because of licensing, not architecture. Renewal quotes on traditional hypervisors can go up by multiples rather than percentages, and analysts expect close to a third of those workloads to move to a different platform by 2028. The trigger there is commercial, so the deadline is a renewal date, not an architecture roadmap. Rearchitecting the database tier is not in scope for teams urgently leaving a hypervisor to avoid renewal costs. What is needed is a way off traditional hypervisors that doesn’t touch how the database runs or blow up the budget doing it. 

How Red Hat OpenShift Virtualization can help

Red Hat OpenShift Virtualization runs VMs and containers side by side on a single control plane. For a team running Postgres on a traditional hypervisor today, that means the established VM-based architecture moves onto OpenShift largely intact, with the runbooks and the operational expertise still valid. You can remove the legacy virtualization dependency on your own timeline, while avoiding a simultaneous database containerization project.

The hybrid version of that works too. Stable production stays on VMs, and new greenfield work goes into containers on CloudNativePG, supported by EDB, on the same platform.

For organizations already running OpenShift for their containerized applications, this collapses a real silo. Instead of a separate virtualization stack for the database and a Kubernetes stack for everything else, there is one platform, one control plane, and one place to look when something breaks at 2 a.m.

The container-native path is still a core part of EDB’s strategy. CloudNativePG was created by EDB and donated to the Cloud Native Computing Foundation, where it’s described as “the most popular Kubernetes operator for PostgreSQL.” OpenShift Virtualization is a complementary path for teams that want platform consolidation now and containerization later.

The validated architecture

EDB engineering validated the full M1 high-availability pattern end to end on OpenShift Virtualization VMs running RHEL 9. Deployment uses Red Hat Ansible Automation Platform, in the same way many customers already drive their production VM builds on bare metal and other hypervisors. The validated architecture consists of:

• High availability: A three-node EDB Postgres 18 cluster, one primary and two streaming replicas
• Failover management: EDB Failover Manager for automatic failover and controlled switchovers
• Backup and recovery: Barman on a dedicated VM, handling continuous WAL archiving and backups
• Observability: Postgres Enterprise Manager for monitoring and alerting

This is the same M1 architecture EDB has been shipping for years, with the VMs running on OpenShift.

EDB is the enterprise Postgres expert

As one of the world’s largest contributors to enterprise Postgres, EDB possesses massive technical knowledge and deep expertise to support every modern use case. Postgres is governed by a small group of committers, the only people permitted to merge code into the source tree. Twenty EDB engineers were patch authors during the Postgres 18 development cycle, contributing roughly 55,000 lines of code to that release, and EDB engineering accounts for more than 30 percent of the meaningful contributions in a typical major version.

A few of those contributions:

• Logical replication in Postgres 10: This made it possible to replicate selected tables between different Postgres versions, which is the foundation the modern zero-downtime upgrade tools depend on.
• MERGE in Postgres 15 and declarative partitioning in Postgres 10: These are the two features most often cited by teams migrating off Oracle.
• JSON_TABLE in Postgres 17: Longtime EDB engineer and PostgreSQL committer Andrew Dunstan was central to the multi-release SQL/JSON effort. JSON_TABLE turns nested JSON documents into queryable relational rows, which removes the glue code that used to be the price of mixing document and relational data.
• Incremental backup in Postgres 17: Only what has changed since the previous backup is captured, which makes frequent backups practical at multi-terabyte scale.
• OAuth authentication in Postgres 18: A native OAuth flow in the database, this is the upstream foundation that EDB’s enterprise OAuth modules build on.

The work extends past the Postgres core. In addition to having created CloudNativePG, EDB maintains Barman, Foreign Data Wrappers, WarehousePG (an open source fork of Greenplum after the original was closed sourced), and PGPU for offloading database operations to NVIDIA GPUs. On top of that, EDB adds the enterprise capability that turns upstream Postgres into EDB Postgres AI: Transparent Data Encryption, Data Redaction, User Profiles, and OAuth modules that integrate with the identity providers enterprises actually run.

When something goes wrong at the database kernel level, EDB can write the fix.

Agents and AI workloads on the same VMs

Taking the VM path does not limit your AI work. The same EDB Postgres AI distribution supported on OpenShift Virtualization includes pgvector for vector similarity search, VectorChord for higher-scale indexing, the AIDB extension for embedding and retrieval pipelines defined in SQL, and graph support for relationship-heavy data models. A team that’s running Postgres on VMs today and wants to add a retrieval workload next quarter does not need to change platforms.

EDB PG AI supports agents as well. It enforces agent governance at the data layer, using native Postgres roles and row-level security rather than a separate policy tool sitting above the database. Since the controls are properties of the database, they behave the same way on a VM that they do in a container.

Running on hardware and a platform you control, under governance enforced inside Postgres, is what data and AI sovereignty means in practice. A hypervisor migration is a common starting point for sovereignty discussions, since customers begin examining their dependencies and who owns them.

Where to start

Teams already on OpenShift mainly need to point the same Ansible Automation Platform workflows at an OpenShift Virtualization namespace, instead of wherever Postgres lives today.

If you are already an EDB customer, your account team can walk you through the validated reference architecture and what it looks like in your environment. If you are new to EDB and considering using Red Hat OpenShift Virtualization, contact us to start a conversation.