live wire
▸AI · Red Hat documents usage-based admission fair sharing for Kueue 1.4 on OpenShiftRed Hat Developer▸AI: Red Hat maps governed firewall changes from ServiceNow through Ansible and two human approval gatesRed Hat Developer▸CLUSTER MGMT · ACM 2.17 makes Submariner 0.24 GA with Important-rated fixesRed Hat Errata▸PLATFORM · Red Hat makes on-premises Lightspeed recommendations GA for Satellite 6.18Red Hat Errata▸SECURITY · Red Hat Hardened Images updates Tomcat 10 for nine authentication, access-control and DoS flawsRed Hat Errata▸AI · Open Data Hub 3.6.0 EA1 bundles Trainer, MLflow and llm-d componentsOpen Data Hub▸AI · Speculators 0.6.0 adds P-EAGLE parallel drafting for vLLM speculative decodingRed Hat Developer▸SECURITY · OpenShift 4.17.57 fixes seven Go and TLS CVEs in an Important-rated updateRed Hat Errata▸AI · Red Hat benchmarks local LLM guardrails with EvalHub, exposing regex accuracy and latency trade-offsRed Hat Developer▸AI · Red Hat maps silent tool-call failures across agentic pipelinesRed Hat▸API · Kuadrant 1.5.3 adds GRPCRoute policies and developer-portal API-key workflowsKuadrant▸AI · (Aug 25) IBM releases Apache-2.0 Granite 4.2 reasoning models in 3B, 8B and 30B sizesIBM Research▸JAVA · Red Hat build of Quarkus 3.33.3.SP1 fixes 13 CVEs in an Important-rated updateRed Hat errata▸AI · vLLM moves Kimi K2 RL weight sync across 384 H100s in 7.53 seconds (Aug 22)vLLM▸AI · Red Hat documents usage-based admission fair sharing for Kueue 1.4 on OpenShiftRed Hat Developer▸AI: Red Hat maps governed firewall changes from ServiceNow through Ansible and two human approval gatesRed Hat Developer▸CLUSTER MGMT · ACM 2.17 makes Submariner 0.24 GA with Important-rated fixesRed Hat Errata▸PLATFORM · Red Hat makes on-premises Lightspeed recommendations GA for Satellite 6.18Red Hat Errata▸SECURITY · Red Hat Hardened Images updates Tomcat 10 for nine authentication, access-control and DoS flawsRed Hat Errata▸AI · Open Data Hub 3.6.0 EA1 bundles Trainer, MLflow and llm-d componentsOpen Data Hub▸AI · Speculators 0.6.0 adds P-EAGLE parallel drafting for vLLM speculative decodingRed Hat Developer▸SECURITY · OpenShift 4.17.57 fixes seven Go and TLS CVEs in an Important-rated updateRed Hat Errata▸AI · Red Hat benchmarks local LLM guardrails with EvalHub, exposing regex accuracy and latency trade-offsRed Hat Developer▸AI · Red Hat maps silent tool-call failures across agentic pipelinesRed Hat▸API · Kuadrant 1.5.3 adds GRPCRoute policies and developer-portal API-key workflowsKuadrant▸AI · (Aug 25) IBM releases Apache-2.0 Granite 4.2 reasoning models in 3B, 8B and 30B sizesIBM Research▸JAVA · Red Hat build of Quarkus 3.33.3.SP1 fixes 13 CVEs in an Important-rated updateRed Hat errata▸AI · vLLM moves Kimi K2 RL weight sync across 384 H100s in 7.53 seconds (Aug 22)vLLM
upstreambeat.ai
guideDATA

Red Hat lays out three database-modernization paths on OpenShift

A new Red Hat engineering guide separates VM-based migrations, RHEL application streams and Kubernetes Operators—and makes the support boundary part of the architecture decision.

Three database paths compared on OpenShift, each with different support models.
Side by side: what changed
By The News Desk· Aug 26, 2026

Red Hat has published a practical framework for deciding how database workloads should land on OpenShift: preserve them as virtual machines, consume Red Hat-packaged databases through RHEL application streams, or adopt container-native databases managed by Kubernetes Operators.

The useful part of the Aug. 26 engineering guide is not a claim that every database should be containerized. It treats support provenance, automation and migration risk as separate design inputs.

Three routes, not one destination

For an existing database already certified or validated on RHEL, Red Hat presents OpenShift Virtualization as the lowest-change route. Those workloads run as VMs on the RHEL Kernel-based Virtual Machine hypervisor while application teams can place containerized services on the same OpenShift platform. The article names Microsoft SQL Server, Oracle Database and RAC, IBM Db2, Percona XtraDB and DataStax among its examples, while directing readers to vendor and Red Hat support matrices for the exact supported configurations.

The second route uses database packages delivered in RHEL application streams. Red Hat cites PostgreSQL, MariaDB and MySQL as examples and says their updates and support are covered through the RHEL subscription and the application-stream lifecycle. This model keeps the database inside a conventional RHEL operational boundary even when the surrounding application estate moves onto OpenShift.

The third route is Kubernetes-native operation. Red Hat points to partner Operators for products including Crunchy Postgres, CockroachDB, EnterpriseDB and MongoDB. Operators can automate recurring work such as backup, patching and scaling, but that operational gain comes with a more substantial change to how teams deploy and manage the database.

The support matrix is an architecture artifact

The guide’s most actionable distinction is between can run and is supported. A RHEL-certified workload, a Red Hat application-stream package and a partner Operator do not inherit support through the same mechanism. Platform teams therefore need to record the database version, guest operating system, deployment form and responsible vendor before choosing a migration path.

That matters especially for the article’s broad compatibility table. It lists deployment possibilities across VMs and containers, but Red Hat explicitly tells readers to consult current catalog listings for version-level details. A platform standard should preserve that qualification rather than turn a product-family example into a blanket certification claim.

What teams should decide first

The three routes imply a sensible sequence: establish the vendor-supported baseline; decide whether the immediate goal is consolidation or application re-architecture; then select the automation model. Teams trying to reduce hypervisor sprawl may reasonably start with database VMs on OpenShift Virtualization. Teams already prepared to change backup, recovery and scaling workflows can evaluate an Operator-led deployment.

The result is a staged modernization model rather than a container mandate. OpenShift can be the common control plane, while each database moves only as far as its support commitments and operating model allow.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk