Nutanix Database Service for Cloud-Native Data
NDB (formerly Era) is Nutanix's database-as-a-service control plane. For NCP-CN the focus is how cloud-native teams consume it: self-service provisioning, clones for dev/test, Time Machine protection, and API-driven automation.
Building blocks
- A registered Nutanix cluster plus a network profile and compute profile define where and how database server VMs land.
- Software profiles pin database versions and parameters; database-parameter profiles tune engines.
- Supported engines include PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, and MongoDB.
- Time Machine captures scheduled snapshots plus transaction logs for point-in-time recovery. Retention is policy-driven and the SLA drives RPO.
- Clones are storage-efficient linked copies and can be refreshed, so a test database can be re-pointed at production data quickly.
Worked example
A team needs a Postgres copy for a staging namespace, current to 10:00. Use NDB to clone the source database with a point-in-time target of 10:00, attach it to the staging network profile, and hand the connection string to the app. Reasoning: Time Machine logs are what make 10:00 possible; a VM snapshot from last night cannot. The clone is thin, so storage does not double.
Traps
Confusing NDB Time Machine with Prism protection-domain VM snapshots - the former is database-aware, the latter VM-level. Assuming NDB creates databases inside the Kubernetes cluster; it provisions database server VMs on registered clusters. Promising an RPO without checking the SLA. Skipping the network profile and then failing to reach the clone.