Continuing this series through the Nutanix portfolio, this post covers Nutanix Database Service (NDB). In the previous post we looked at Nutanix Unified Storage and how it consolidates file, object, and block services. NDB sits a layer above that: it manages the databases themselves.
The problem it addresses is familiar to anyone who has run a database estate of any size. Provisioning takes days because it involves tickets. Patching is deferred because it is tedious and risky. Developers wait on refresh requests. Meanwhile, the number of databases keeps growing, and the DBA team does not.
Applies to: Nutanix Database Service 2.11 (July 2026).
First, the name
If you have been around Nutanix for a few years, you knew this product as Nutanix Era. It was renamed Nutanix Database Service, and NDB is the current name.
This matters more than a rebrand usually would, because the old name persists in places you will actually encounter it. Community threads, older documentation, and some in-product strings and log entries still reference Era. If you are searching for a solution to a problem, searching both names will find you more.
Which databases it manages
NDB manages the mainstream enterprise engines rather than trying to cover everything:
- Microsoft SQL Server, including Always On Availability Groups
- Oracle Database
- PostgreSQL, both community edition (including the pgvector extension) and EDB Postgres
- MySQL, including Enterprise Edition
- MariaDB
- MongoDB, including sharded clusters on MongoDB Enterprise Advanced
EDB became an officially supported engine through an expanded Nutanix and EnterpriseDB partnership, which matters for organizations moving off Oracle and relying on EDB’s Oracle compatibility features. Support for pgvector means the same platform can also run the vector databases retrieval-augmented AI applications depend on.
Specific supported versions move with each NDB release, and so do the supported guest operating systems. Treat any version list you read, including this one, as a starting point and confirm it against the release notes for your NDB version.
What it actually automates
Four capabilities account for most of the value.
Provisioning. A database is deployed from a standardized profile that encodes your configuration alongside Nutanix best practices. The point is not that it is fast, though it is; the point is that every database provisioned this way is built the same, so the estate stays consistent instead of accumulating one-off configurations.
Copy data management. This was NDB’s original offering and is still the capability people notice first. Using space-efficient snapshots, it clones and refreshes databases to any point in time without duplicating the full data footprint. A development team can refresh from production in minutes rather than scheduling a copy that consumes another full-size volume.
Patching. Bulk patching across the fleet, applied consistently, is the third. This is the task most likely to be deferred indefinitely when done by hand, and deferred patching is how estates end up with unsupported versions in production.
Point-in-time recovery. You can restore to a specific transaction rather than to last night’s backup, with the recovery workflow driven from the same interface as everything else.
All of it is available through UI, CLI, and API. The API matters if you intend to wire database provisioning into a self-service catalog or a pipeline, which is where most of the operational payoff actually lands.
High availability and disaster recovery
The last three releases pushed NDB well beyond copy data management and into resilience, making it viable for production rather than just dev and test. The pattern across engines is consistent: NDB uses each database platform’s own native HA and DR mechanisms, but drives them through one interface.
NDB 2.9 (October 2025) added disaster recovery for Oracle through Oracle Data Guard, including Cascaded Data Guard for multiple standby systems. It also added provisioning of MySQL high-availability clusters built on native components (InnoDB, Group Replication, and MySQL Router) rather than third-party tooling.
NDB 2.10 (April 2026) focused on MongoDB. It automated sharded cluster provisioning and added a MongoDB-certified backup integration with Ops Manager, with point-in-time recovery down to the second. MySQL HA clusters could now be built from the GUI, not just the API and CLI.
NDB 2.11 (July 2026) is the biggest step so far. PostgreSQL gained disaster recovery with real-time streaming replication, one-click failover, and WAL archiving to Nutanix Objects. SQL Server Availability Groups (up to nine nodes), PostgreSQL clusters (up to five nodes), and MongoDB sharded clusters can now be scaled out with near-zero downtime. MySQL HA clusters gained backup, restore, and point-in-time recovery.
Security, governance, and where it runs
NDB 2.11 also closed several gaps that security teams tend to raise first. MySQL and EDB Postgres now support Transparent Data Encryption with automated key rotation through an external key management service, including Thales. A structured audit trail can be forwarded to Splunk, QRadar, or Datadog, and role-based access control is now more granular, so you can delegate provisioning and cloning without handing over the whole platform.
NDB runs on Nutanix clusters on-premises and on Nutanix Cloud Clusters (NC2). With 2.11 it added Google Cloud to AWS and Azure, so the same operational model covers all three major hyperscalers. You still operate the software yourself in each location; it is not a managed database service in the RDS sense.
Constraints worth knowing before you deploy
These boundaries catch people after the fact, and they are easier to design around than to discover later. They have appeared in the NDB documentation across many releases, but check the limitations section of the user guide for your version before you plan around them:
- The NDB server and agent cannot be migrated to a different storage container within a cluster, or to a different cluster
- User VMs managed by NDB cannot be migrated to a different Nutanix cluster
- Database server VMs provisioned by NDB should not be added to protection domains
- Databases on non-AOS platforms, and database servers protected by Metro Availability, are not supported
- Active Directory authentication is not supported for Linux database servers
The first two are the ones to internalize. Where you place the NDB server and its managed databases is close to a permanent decision, so it deserves more thought than a typical VM placement.
The protection domain item is worth calling out separately because it is easy to get wrong by habit. NDB manages protection for the databases it provisions; adding those VMs to a protection domain as well creates two systems trying to protect the same thing.
Summary
NDB, formerly Era, is a database-as-a-service layer for SQL Server, Oracle, PostgreSQL and EDB, MySQL, MariaDB, and MongoDB, running on Nutanix on-premises and on NC2 in AWS, Azure, and Google Cloud. It automates provisioning, cloning and refresh, patching, and point-in-time recovery. Releases 2.9 through 2.11 added native HA and DR for every major engine, near-zero-downtime scale-out, and the encryption and audit controls that production estates require.
The value shows up at scale, not on a single database. If your DBAs spend their time on refresh requests and deferred patching instead of schema, query performance, and data design, NDB is built to remove that problem. Settle the placement decisions early, because several of them are not reversible.
Related reading: Discovering Nutanix: Nutanix Unified Storage (NUS), for the storage services that sit underneath NDB, and Nutanix .NEXT 2026 Announcements and Recap, for where databases and AI fit in the wider Nutanix roadmap.
Sources:
- Nutanix Database Service product overview, Nutanix
- Nutanix Database Service (NDB) 2.11 is here!, Nutanix Community
- Nutanix Database Service 2.11: Scaling, Security, and Multi-Cloud, Efficiently Connected
- Nutanix Database Service (NDB) 2.10 release announcement, Nutanix blog
- Nutanix Database Service (NDB) 2.9 release announcement, Nutanix blog
- Nutanix Database Service forum, Nutanix Community
Are you running NDB for production databases, or still using it mainly to give developers fast clones of production data?
Let me know in the comments below.
Leave a Reply