Hi Haitham,

I looked into this a bit more, including how the Mendix Operator itself handles it, and the short answer is: the platform does not give you true zero-downtime when a schema change is involved. It deliberately avoids it.

Here's why. The Mendix on Kubernetes Operator uses a Recreate strategy by default (stop everything, then start the new version). Starting from Operator 2.25.0, it will automatically do a Rolling update instead, but only when the configuration change does not modify the app model, MDA, or container image. Any change that does modify the MDA which includes every schema change, since a schema change always comes from a domain model change causes a full restart and downtime, by design.

Interestingly, Operator versions 2.20.0 to 2.23.1 did have an experimental option that tried to perform database schema upgrades using a Rolling strategy. Mendix removed it in 2.24.0 because it didn't work well with the latest Mendix Runtime security features. So this was tried at the platform level and pulled back out, which tells you it's a genuinely hard problem, not something they just haven't gotten to yet.

What the built-in mechanism does cover is narrower: things like app constants, the MxAdmin password, debugger settings, environment variables, Runtime/Java options, and Runtime Metrics settings can be rolled out without downtime, because none of those touch the model or the schema.

So to answer your specific questions:

• Blue-green vs rolling at the OpenShift level: both work fine as deployment mechanics (new pods/route ready before old ones go away), but neither solves the schema problem by itself. They just move traffic; they don't make an old and a new app version simultaneously compatible with a changed schema.
• How to actually get close to zero-downtime with schema changes: you have to do it yourself with an expand/contract approach — add new columns/entities without removing old ones (a release the old version tolerates), let traffic drain to the new version, then a follow-up release does the cleanup (drop deprecated columns). Disable automatic domain-model synchronization for that cutover release and drive it with your own migration logic instead, so you control exactly when the schema actually changes shape.
• HA Postgres solves database availability/failover, but it's a separate concern from this — it doesn't make a breaking schema change safe for two app versions to share.

In practice, most Mendix-on-OpenShift/Kubernetes teams get "near-zero-downtime" — a short cutover window during the contract step — rather than mathematically true zero-downtime, precisely because of what's described above.

Reference: Reducing Deployment Downtime in the Mendix docs, which covers the Operator's Recreate/Rolling behavior in detail.

Kindly mark this as the accepted answer if it helps.

Hi,

The two-rack/OpenShift + HA PostgreSQL architecture can certainly provide a highly available platform, but there is an important limitation on the Mendix side when the deployment contains application model/database schema changes.

With the current Mendix on Kubernetes Operator, a rolling deployment is intended for changes that do not modify the application model. When a new MDA/container image is deployed, the Operator uses the recreate strategy, which means the existing replicas are stopped before the new version is started.

In particular, I would not rely on Blue-Green/Rolling deployment to make a Mendix database-model change zero-downtime. The difficult part isn't OpenShift or PostgreSQL HA; it is that two different Mendix application models may need to run against the same database during the transition.

There was actually an experimental rolling strategy in Mendix Operator 2.20–2.23.1 that could also attempt database schema upgrades. Mendix removed this in Operator 2.24 because it did not work well with the newer Mendix Runtime security features. So I would not build a production architecture around that older approach.

The current documented behavior is roughly:

Configuration-only change
        ↓
Rolling update
        ↓
Old + new replicas can coexist
        ↓
Traffic switches to new version

Application model / MDA / schema change
        ↓
Recreate
        ↓
Existing replicas stopped
        ↓
New version starts

The Operator documentation also explains that during a rolling update multiple versions can temporarily exist, and Mendix uses Kubernetes service labels to perform the traffic switchover. That is precisely why the application versions need to be compatible during that period.

So for your specific requirement, I would separate the two goals:

1. Platform HA

Your two-rack OpenShift setup + HA PostgreSQL is a good foundation for avoiding infrastructure-level failures.

2. Deployment without application downtime

For configuration changes, use the Mendix Operator's rolling deployment capabilities. Current documentation says Operator 2.25+ automatically uses rolling updates when the update does not modify the app model.

3. Domain-model/database changes

These should be planned as deployments that require the Mendix application restart. I would not try to bypass the Operator's recreate behavior by manually modifying the generated Deployment/Service resources; Mendix explicitly warns against modifying resources that are managed by the Operator.

If your business requirement is strict zero downtime even when the domain model changes, I would raise this with Mendix Support/your Mendix account team before designing a custom blue-green implementation. The supported Mendix deployment model does not currently provide a general-purpose "old Mendix model + new Mendix model sharing one database" migration mechanism.

In other words, PostgreSQL HA can keep the database available, but it does not by itself make a Mendix application-model migration zero-downtime.

One more practical point: don't treat database schema migration as an independent PostgreSQL migration that can simply be performed ahead of the application deployment. Mendix owns the application model/schema mapping, so the compatibility between the deployed Mendix model and database needs to be considered as part of the Mendix deployment.

For reference, Mendix officially supports Red Hat OpenShift through Mendix on Kubernetes, and the current documentation covers the Operator deployment and reduced-downtime strategies.

So my recommendation would be: use rolling deployment for configuration-only changes, and plan a controlled restart/maintenance window for deployments containing domain-model/schema changes rather than trying to force a blue-green deployment against the same database.