Databases and caching on OpenShift
Oracle, PostgreSQL, Redis and Red Hat Data Grid run as a platform: automated, replicated to a second site, backed up, and failed over on a schedule rather than in a crisis.
Databases that are provisioned in minutes and recovered in rehearsed steps
The database is where an institution's risk concentrates: the core ledger, the customer records, the case files. Most are still built by hand, one server at a time, backed up to a schedule nobody has tested, and protected by a disaster recovery site that has never carried production traffic.
We run databases and caches as a platform on Red Hat OpenShift. PostgreSQL clusters come from the Crunchy Data operator with replication, backups and monitoring built in; Oracle keeps its place for the core and is replicated with Data Guard; Redis and Red Hat Data Grid take the read load and the sessions off the databases. Every one of them is replicated to the second site and failed over on a schedule, with the applications running.
When it fits
01
Every database is a snowflake
Each one was installed by a different person on a different version, and only one engineer knows how it is backed up.
02
The DR site has never been used
Replication is configured, but nobody has switched production to the second site and back.
03
The core database is the bottleneck
Reporting queries and session lookups compete with transactions, and response times climb at month end.
04
New applications wait for a database
A PostgreSQL instance for a new service takes a ticket and weeks, so teams run their own unsupported copies.
What we do
PostgreSQL on OpenShift
High-availability clusters from the Crunchy Data operator, with streaming replication, point-in-time backups, connection pooling and monitoring, provisioned as code.
Oracle across DC and DR
Oracle Database and Exadata protected with Data Guard, switchover and failover procedures, and GoldenGate feeds into the rest of the platform.
Caching and in-memory data
Redis for caching, sessions and queues, and Red Hat Data Grid for Java and .NET applications, with cross-site replication where needed.
Backup and restore
Backups to object storage at both sites, restore tests on a schedule, and retention that matches the regulator's rules.
Disaster recovery drills
Rehearsed failover and failback for every database and cache, with the applications running, measured against agreed recovery objectives.
Migration and consolidation
Move databases off ageing servers and costly licences onto the platform, with a cutover that can be reversed.
DC and DR
Every database replicated, every failover rehearsed
The primary site runs the databases and the cache layer in front of them. Changes stream to the disaster recovery site continuously, and on a schedule we switch production over, run it there, and switch back, so the recovery you have on paper is the recovery you actually have.
- Primary site
- Oracle and PostgreSQL databases on OpenShift, serving the applications.
- Cache layer
- Redis and Data Grid taking the read load, sessions and queues off the databases.
- Replication
- Continuous streaming of changes to the second site, with lag monitored.
- Disaster recovery site
- Standby databases that take over in a drill or an outage, then hand back.
How a database programme runs
01
Inventory
List every database and cache, its version, owner, backup state, recovery objective and the applications that depend on it.
02
Design
Design the platform, the replication topology, backup retention and the failover procedures, and size both sites.
03
Build and migrate
Build the platform as code, migrate databases in waves with reversible cutovers, and move caching in front of the busiest ones.
04
Rehearse and run
Run the first disaster recovery drill, fix what it finds, then operate the platform under agreed service levels.
What you get
- A database platform on OpenShift with PostgreSQL, Redis and Data Grid provisioned as code
- Oracle protected across two sites with documented switchover and failover
- Backups at both sites with tested restores and agreed retention
- A disaster recovery drill completed, with its report and the fixes it required
- Monitoring, alerting and capacity dashboards for every database and cache
- Runbooks and training for your database team
What we build with
Supported databases and caches, run the same way on both sites.
Databases
- Oracle Database and Exadata
- Oracle Data Guard
- PostgreSQL
- Crunchy Postgres for Kubernetes
- pgvector
Caching and in-memory
- Redis
- Red Hat Data Grid
- Valkey
Platform and storage
- Red Hat OpenShift
- NetApp Trident
- Dell Container Storage Modules
- OpenShift Data Foundation
Questions about databases on the platform
Can Oracle run on OpenShift?
Oracle usually stays on its own servers or Exadata, where its licensing and support are clearest, and the platform connects to it: Data Guard for the second site, GoldenGate or Debezium to stream its changes, and PostgreSQL on OpenShift for the applications around the core.
Is PostgreSQL on Kubernetes safe for production?
Yes, with an operator that handles replication, failover and backups. We use Crunchy Postgres for Kubernetes, which runs in our lab across DC and DR, and we test restores and failover before any production data arrives.
How often should we fail over?
Often enough that it is routine: at least twice a year for the core databases, more for the rest. Each drill is scheduled, announced, measured against the recovery objectives and reported.
Do caches need a DR site too?
It depends on what they hold. A cache that can be rebuilt from the database can stay single-site; sessions and queues usually cannot. Redis and Data Grid both replicate across sites, and the design says which caches do.
Redis labs from our engineersRun your databases as a platform
Tell us what you run and when you last failed over. We'll propose a first step, whether that is a disaster recovery drill, a PostgreSQL platform or a migration plan.