One Database, Twenty-Six Landing Zones
EMEA PUBLIC SECTOR SERIES
This article is part of the EMEA Public Sector series, exploring why data sovereignty has become a critical priority for governments and public institutions across Europe, the Middle East, and Africa. As regulatory pressure, geopolitical risk, and AI adoption reshape digital strategies, data sovereignty is emerging as a key pillar of modern public sector data platform architectures, enabling control, resilience, and trusted digital services.
In public sector meetings, the first question about a database is rarely about features. It is about location. Can it run inside our national cloud? On the partitions we already pay for on IBM Z? On the OpenShift platform we standardized on three years ago? In a network that will never, by design, see the internet?
These are not edge cases. For ministries, defense organizations, health authorities and central banks, the landing zone is decided before the application is. Classification levels, procurement frameworks, national cloud strategies and existing infrastructure investments define where data is allowed to live. The data platform has to follow that mandate, not the other way round.
So here is the full map: twenty-six ways to run MongoDB across hybrid, sovereign and public cloud environments, grouped by category, with the support model that applies to each.
What This Map Covers, and What It Does Not
This matrix focuses on environments where the customer, or a European provider acting on its behalf, operates the platform. It deliberately leaves out MongoDB Atlas, the fully managed developer data platform on AWS, Azure and Google Cloud, which deserves its own discussion. The public cloud entries below refer to self-managed deployments on IaaS virtual machines.
The same MongoDB engine, drivers and query API run across every option. What changes is who operates the infrastructure, who operates the database, and who you call when something breaks.
Three Support Models
- Supported by MongoDB. The organization runs MongoDB on its own hardware, hypervisor or IaaS, typically under a MongoDB Enterprise Advanced subscription, and MongoDB supports the database directly.
- Supported via sovereign cloud. A European provider delivers MongoDB as a managed service and operates it within its own service model, jurisdiction and certifications. The provider is the first point of contact.
- Supported through the Kubernetes Operator. The platform meets the requirements of the MongoDB Kubernetes Operator, which deploys and manages MongoDB as a Kubernetes-native workload, from provisioning to upgrades and day-2 operations.
1. Bare Metal
The simplest answer, and for some workloads still the best one. Direct installation on customer hardware removes the virtualization layer entirely, gives full control over storage, memory topology and networking, and keeps the dependency chain as short as possible. It remains common in high-performance and high-security environments where every layer in the stack has to justify its presence.
- Customer hardware, direct installation. Supported by MongoDB.
2. European Sovereign Cloud
This is where the sovereignty debate becomes concrete. European providers now offer MongoDB as a managed service inside EU legal and operational jurisdiction, several of them backed by national qualification schemes, while others provide the sovereign infrastructure on which MongoDB runs self-managed. For administrations bound by national cloud strategies, this is often the shortest path from policy to production.
- Cleura (formerly City Network): managed database service operated by Cleura on its European cloud, with MongoDB among the supported engines.
- OVHcloud: managed MongoDB on OVHcloud Public Cloud, from a provider whose sovereign offerings carry SecNumCloud qualification (France, EU).
- T-Systems (Open Telekom Cloud): IaaS virtual machines on a KVM-based European cloud with BSI C5 certification (Germany, EU). Here MongoDB runs self-managed and is supported by MongoDB directly.
- IONOS Cloud: managed MongoDB DBaaS, with Business and Enterprise editions, on European cloud infrastructure.
- Scaleway: Managed MongoDB, a Certified by MongoDB DBaaS offering on European cloud infrastructure.
- Aruba Cloud: IaaS virtual machines (Aruba Cloud Server) from a key player in the Italian market, for both enterprise and public administration. MongoDB runs self-managed and is supported by MongoDB directly.
- Polo Strategico Nazionale (PSN): MongoDB Enterprise Edition as a managed PaaS service in the PSN catalogue, on the critical infrastructure built for the Italian public administration’s highest security requirements.
- Outscale (Dassault Systèmes): IaaS virtual machines on a hyper-secure cloud with SecNumCloud qualification. As with T-Systems and Aruba, MongoDB runs self-managed and is supported by MongoDB directly.
The sovereign landscape keeps growing beyond this list. STACKIT, for example, offers MongoDB Flex, a fully managed MongoDB service with replica sets and sharded clusters, operated from data centers in Germany and Austria.
For a closer look at these providers and how each one delivers MongoDB, see Beyond Hyperscalers: MongoDB Offerings Across Europe’s Sovereign Clouds.
3. On-Premises Hypervisors
Most public sector estates are not greenfield. They are the result of decades of investment in virtualization platforms, operational tooling and skills. MongoDB runs as a supported workload on every major hypervisor, so modernization can start on the infrastructure already in place instead of waiting for a platform migration.
- IBM PowerVM / IBM Z: LPAR partitions on IBM Power (ppc64le) and IBM Z (s390x), both supported platforms for MongoDB Enterprise, keeping modern workloads next to the systems of record. This is the natural landing zone for the approach I described in Beyond Code Translation.
- VMware vSphere / ESXi: the market standard for enterprise virtualization.
- Nutanix AHV: optimized integration for hyperconverged infrastructure (HCI), with Nutanix Database Service automating the MongoDB lifecycle alongside Ops Manager.
- Microsoft Hyper-V: supported for both Windows and Linux guests.
- KVM: Linux kernel virtualization, widely used across enterprise open-source stacks.
- Citrix Hypervisor / XenServer.
The hypervisor question is less neutral than it used to be. Recent licensing changes in the virtualization market have pushed many organizations to reassess their platform. A data layer that runs identically on VMware, Nutanix, Hyper-V and KVM turns that reassessment into an infrastructure decision rather than a database migration.
4. Orchestration and Containers
For organizations standardizing on Kubernetes, MongoDB runs through its Kubernetes Operator, which expresses deployment, scaling, upgrades and backup as declarative resources. Any distribution that meets the operator requirements is supported, which lets platform teams keep one operating model for applications and data.
- Red Hat OpenShift: the reference platform for enterprise containerized workloads.
- VMware Tanzu: tight integration with the on-premises VMware ecosystem.
- SUSE Rancher (RKE): optimized management for multi-cluster scenarios.
- Vanilla Kubernetes: upstream Kubernetes on any conformant infrastructure.
5. Private Cloud
OpenStack remains the foundation of many national, research and provider clouds in Europe. MongoDB can run on its virtual machines or through the Kubernetes Operator on top, which makes private cloud a bridge between classic virtualization and a fully containerized estate.
- OpenStack / CloudStack: virtual machines or Kubernetes Operator, for building on-premises private clouds.
6. Air-Gapped
This is where requirements are least negotiable. Defense, intelligence and classified government workloads often run in environments with no connection to the outside world, by design. The major hyperscalers now ship disconnected versions of their stacks, and MongoDB runs on all three through the Kubernetes Operator.
- Google Distributed Cloud (GDC) air-gapped: MongoDB Enterprise Advanced is installed through the Kubernetes Operator from GDC’s built-in, isolated marketplace.
- AWS EKS Anywhere: air-gapped Kubernetes clusters on customer infrastructure, fed from a local registry mirror with no dependency on AWS services.
- Microsoft Azure Local: disconnected operations mode, running an AKS cluster or virtual machines.
In a disconnected environment, operations have to be self-sufficient. Container images, binaries, monitoring and backup all live inside the perimeter, and automation must never depend on reaching anything outside it. Designing for that from day one is far cheaper than retrofitting it.
7. Public Cloud IaaS
Self-managed MongoDB on hyperscaler virtual machines fits organizations that want public cloud elasticity while keeping database operations under their own procedures, or that need to mirror an on-premises architecture one to one.
- Google Cloud: IaaS virtual machines on a custom KVM hypervisor.
- Amazon Web Services: IaaS virtual machines on the Nitro/KVM hypervisor.
- Microsoft Azure: IaaS virtual machines on the Hyper-V hypervisor.
The Full Matrix
| # | Category | Platform / Provider | Deployment Type | Notes | Support Model |
|---|---|---|---|---|---|
| 1 | Bare metal | Customer’s hardware | Direct installation | Supported by MongoDB | |
| 2 | European Sovereign Cloud | Cleura (ex City Network) | Managed database service | Operated by Cleura on its European cloud, MongoDB among supported engines | Supported via sovereign cloud |
| 3 | European Sovereign Cloud | OVHcloud | DBaaS Managed | Managed MongoDB on OVHcloud Public Cloud; provider with SecNumCloud-qualified offerings (France/EU) | Supported via sovereign cloud |
| 4 | European Sovereign Cloud | T-Systems (Open Telekom Cloud) | IaaS, virtual machines | KVM-based Elastic Cloud Server, BSI C5 certification (Germany/EU) | Supported by MongoDB |
| 5 | European Sovereign Cloud | IONOS Cloud | DBaaS Managed | Managed MongoDB, Business and Enterprise editions | Supported via sovereign cloud |
| 6 | European Sovereign Cloud | Scaleway | DBaaS Managed | Certified by MongoDB DBaaS on European cloud infrastructure | Supported via sovereign cloud |
| 7 | European Sovereign Cloud | Aruba Cloud | IaaS, virtual machines | Aruba Cloud Server; key player for the Italian market, enterprise and PA | Supported by MongoDB |
| 8 | European Sovereign Cloud | Polo Strategico Nazionale (PSN) | PaaS Managed | MongoDB Enterprise Edition in the PSN catalogue; critical infrastructure for the Italian PA | Supported via sovereign cloud |
| 9 | European Sovereign Cloud | Outscale (Dassault Systèmes) | IaaS, virtual machines | Hyper-secure cloud with SecNumCloud qualification | Supported by MongoDB |
| 10 | Hypervisor on-premises | IBM PowerVM / IBM Z | LPAR partitions | IBM Power (ppc64le) and IBM Z (s390x) architectures | Supported by MongoDB |
| 11 | Hypervisor on-premises | VMware vSphere / ESXi | Virtual machines | Market standard virtualization | Supported by MongoDB |
| 12 | Hypervisor on-premises | Nutanix AHV | Virtual machines | Hyperconverged infrastructure (HCI), NDB lifecycle automation with Ops Manager | Supported by MongoDB |
| 13 | Hypervisor on-premises | Microsoft Hyper-V | Virtual machines | Windows and Linux guests | Supported by MongoDB |
| 14 | Hypervisor on-premises | KVM | Virtual machines | Linux kernel virtualization, widely used in enterprise open-source stacks | Supported by MongoDB |
| 15 | Hypervisor on-premises | Citrix Hypervisor / XenServer | Virtual machines | Supported by MongoDB | |
| 16 | Orchestration and containers | Red Hat OpenShift | Kubernetes Operator | Reference platform for enterprise containerized workloads | Supported (meets MongoDB Kubernetes Operator requirements) |
| 17 | Orchestration and containers | VMware Tanzu | Kubernetes Operator | Tight integration with the on-prem VMware ecosystem | Supported (meets MongoDB Kubernetes Operator requirements) |
| 18 | Orchestration and containers | SUSE Rancher (RKE) | Kubernetes Operator | Optimized management for multi-cluster scenarios | Supported (meets MongoDB Kubernetes Operator requirements) |
| 19 | Orchestration and containers | Vanilla Kubernetes | Kubernetes Operator | Any CNCF-certified distribution | Supported (meets MongoDB Kubernetes Operator requirements) |
| 20 | Private cloud | OpenStack / CloudStack | Virtual machines / Kubernetes Operator | On-premises private clouds | Supported (meets MongoDB Kubernetes Operator requirements) |
| 21 | Air-gapped | Google Distributed Cloud (GDC) air-gapped | Kubernetes Operator | Installed from GDC’s built-in, isolated marketplace | Supported (meets MongoDB Kubernetes Operator requirements) |
| 22 | Air-gapped | AWS EKS Anywhere | Kubernetes Operator | Air-gapped clusters on customer infrastructure with a local registry mirror | Supported (meets MongoDB Kubernetes Operator requirements) |
| 23 | Air-gapped | Microsoft Azure Local | Kubernetes Operator / Virtual machines | Disconnected operations mode, running an AKS cluster or virtual machines | Supported (meets MongoDB Kubernetes Operator requirements) |
| 24 | Public cloud | Google Cloud (GCP) | IaaS, virtual machines | Custom KVM hypervisor | Supported by MongoDB |
| 25 | Public cloud | Amazon Web Services (AWS) | IaaS, virtual machines | Nitro/KVM hypervisor | Supported by MongoDB |
| 26 | Public cloud | Microsoft Azure | IaaS, virtual machines | Hyper-V hypervisor | Supported by MongoDB |
Also worth tracking in the sovereign space: STACKIT MongoDB Flex, a managed MongoDB service operated from data centers in Germany and Austria, supported via sovereign cloud.
How to Choose
Twenty-six options is not a menu. In practice the choice narrows quickly once four questions are answered.
- Classification and connectivity. What is the highest classification of the data, and is the environment allowed to connect to anything outside its perimeter? That single answer separates air-gapped deployments from everything else.
- Who operates the data. Does the organization want to run the database itself, or delegate operations to a qualified provider? That is the line between self-managed deployments and sovereign managed services.
- What is already in place. Mainframe partitions, a VMware estate, an OpenShift platform team. The cheapest landing zone is usually the one that already has skills and processes around it.
- How you get out. Every landing zone should come with an exit path. Because the engine, drivers and query API are the same everywhere, moving between these options is a data migration, supported by tools such as Cluster-to-Cluster Sync, not an application rewrite.
The Point Behind the Matrix
Sovereignty is often framed as a question of infrastructure: whose data center, whose jurisdiction, whose keys. That matters. But architectural optionality is decided one layer up. If the data platform runs in only one place, every other sovereignty choice is constrained by it. If it runs in twenty-six, the decision goes back where it belongs: to the policy, the risk assessment and the mission.
For the broader picture of how Europe’s public sector platform is taking shape, see Europe’s New Public-Sector Stack Is Not a Cloud. It Is a Coalition.
Support scope, provider offerings and certifications evolve over time. Sources in the matrix were checked in September 2026; always confirm the current status with MongoDB and with the provider before committing to an architecture.
