- Database self-service in VCF Automation 9 is delivered by VMware Data Services Manager (DSM), a VCF Advanced Service licensed separately from the VCF core.
- It lives in the All Apps organization: DSM runs as a Supervisor Service (the Consumption Operator) alongside the DSM provider appliance.
- The infrastructure policy decides everything. A DSM-managed policy places the database on classic vSphere compute; a vSphere-namespace-backed policy runs it on a VKS cluster.
- Engine support through the self-service portal trails the appliance. Postgres landed first; SQL Server 2022 arrived with DSM 9.1. Verify per version before you promise it.
- My take: wire DSM in only after projects, quotas and a backup policy exist. A self-service database with no lease and no backup default is a liability, not a feature.
A tenant developer files a ticket for a Postgres instance with 4 vCPU, 16 GB RAM and nightly backups. In a VCF Automation shop that has wired up Data Services Manager, that ticket should not exist. The developer opens the catalog, picks a database, fills four short forms, and a managed cluster shows up as a deployment they own. The work moves from your DBA queue to a policy you wrote once. That is the promise. The reality has three sharp edges: a separate license, an infrastructure-policy choice that quietly decides where the database runs, and engine support that does not always match what the DSM appliance can do.
Where database self-service actually lives
VCF Automation does not provision databases itself. It brokers requests to VMware Data Services Manager, which owns the database lifecycle: provisioning, patching, backup and restore, scaling, and point-in-time recovery. DSM is a VCF Advanced Service. That phrase matters for budgeting, because it is licensed separately from VCF core. If your VCF entitlement does not include DSM, the database tile never appears and no amount of catalog work changes that.
The integration is an All Apps organization capability. DSM publishes a Supervisor Service called the Consumption Operator that runs on the Supervisor cluster, and a separate DSM provider appliance that does the actual database management. VCF Automation connects to the provider appliance from the provider organization, then exposes the database service to tenants. If you are still living entirely in the VM Apps world, this is one of the clearest reasons to stand up an All Apps org.
The pieces that have to line up
Four things must exist before a tenant sees a database tile: a DSM provider appliance registered to vCenter, the DSM Consumption Operator installed as a Supervisor Service, a Data Services connection configured in the VCF Automation provider org, and a Data Service Policy that publishes the offer to a tenant. Miss any one and the symptom is the same unhelpful one: an empty Services menu in the tenant org. The first thing I check when a tenant reports a missing database tile is the Data Service Policy scope, because that is the join between what DSM can do and what this specific tenant is allowed to request.
The infrastructure policy decision
This is the choice that people skip and then regret. DSM offers two kinds of infrastructure policy, and the one you pick decides where every database created under it actually runs. A DSM-managed policy is built from raw vSphere primitives: compute resources that share a storage policy, a storage policy, compatible network port groups, an IP pool, a VM folder, and one or more VM classes. A vSphere-namespace-backed policy is different. It points at a Supervisor namespace, and the namespace dictates the available CPU, memory, storage and network. When the policy is namespace-backed, the database is created on a vSphere Kubernetes Service (VKS) cluster.
Why care? Because the two models put your databases in different operational worlds. Namespace-backed placement inherits quota, identity and network guardrails straight from the Supervisor namespace, which is the model you want if you already run a Kubernetes-first platform and want one set of tenancy boundaries. DSM-managed placement keeps databases on classic vSphere objects you already monitor with the rest of your estate. What I tell clients: pick namespace-backed if your tenancy story is already built on Supervisor namespaces and projects; pick DSM-managed if your DBAs live in vCenter and the database fleet should look like every other VM workload to them.
| Aspect | DSM-managed policy | vSphere-namespace-backed policy |
|---|---|---|
| Where the DB runs | Classic vSphere compute | VKS cluster |
| Resource definition | Compute, storage policy, port groups, IP pool, VM classes | Inherited from the Supervisor namespace |
| Tenancy fit | vCenter-centric estates | Kubernetes-first platforms |
| Guardrails | Defined in the policy | Namespace quota, identity, network |
| Who feels at home | DBAs and vSphere admins | Platform and K8s teams |
Wiring the provider side
On the VCF Automation side, the connection is short: in the provider organization, go to VCF Services, then Data Services, then Configure Service. You supply the DSM appliance FQDN and an admin username and password, run Test Remote Connection, and confirm. Then you create a Data Service Policy for Automation that scopes which tenants and projects can consume the service. That policy is the governance seam, and it is separate from the data service policy you may have created inside DSM itself for direct DSM-UI consumption.
The part that actually bites is the Supervisor Service install. The DSM Consumption Operator is registered as a Supervisor Service in vCenter and configured from a values file. Get the certificate or the isSupervisor flag wrong and the service comes up but never brokers a request. Here is the shape of that values file, with the parameters that matter.
# values.yaml for the DSM Consumption Operator (Supervisor Service)
consumptionClusterName: supervisor-wld01 # name of the Supervisor on the cluster
endpoint: https://dsm-provider.corp.local # DSM provider appliance FQDN
rootCA: LS0tLS1CRUdJTiBDRVJU... # base64 PEM of the DSM appliance CA
user: dsm-admin # DSM administrator account
password: REDACTED # DSM admin password
isSupervisor: true # MUST be true for Supervisor install
# image: only override for air-gapped; point packages.broadcom.com at your local registryExpected result: the Data Services Manager Consumption Operator shows Configured under the Supervisor Services list, and the provider org reports the Data Services connection as healthy. Failure mode I see most: a working Test Remote Connection but no database tile for tenants. That is almost never the values file. It is the Data Service Policy scope, or the engine not being enabled on the DSM appliance.
The values that bite
The rootCA must be the base64-encoded PEM of the DSM appliance certificate, not the vCenter one. The simplest way to get it wrong is to export the wrong tab. The isSupervisor flag is binary and unforgiving: false is for a non-Supervisor install and will leave you debugging a service that looks fine. For air-gapped sites, both the imgpkgBundle in the package definition and the image in this values file must point at your local registry, or the service will hang trying to reach packages.broadcom.com.
What the tenant actually does
Once the provider side is healthy, the tenant experience is short and that is the point. In the tenant All Apps organization, a user goes to Build & Deploy, then Services, then Database, and clicks Create. They walk four panes: Basic Information (name, engine, version), Infrastructure Parameters (the policy and sizing that your guardrails permit), Backup and Maintenance (backup window, retention, maintenance schedule), and Advanced Settings. The summary pane confirms, and the request becomes a managed cluster that the tenant owns as a deployment. They get the database; they never touch the Supervisor, the DSM appliance, or vCenter.
Day-2 and the governance line
The reason DSM is worth the separate license is day-2, not day-0. Provisioning a database is the easy part. DSM automates the work that usually eats DBA time: patching, backup and restore, scaling, point-in-time recovery, and for SQL Server 2022 automated failover clustering with sub-30-second recovery and always-on availability groups. The phrase Broadcom uses is self-service for developers, governance for IT, and it is a fair description of the split. Developers self-serve through the catalog. You, as the platform owner, set the guardrails: which engine versions are offered, which storage tiers, what backup frequency is the default, and what a tenant is allowed to size.
Tie those guardrails to the same governance you already run for VMs. A database with no lease and no backup default is the most expensive kind of orphan, because it holds state. Use your approval, lease and day-2 policies so that a self-service Postgres cluster cannot be created without a retention setting, and so that abandoned instances surface instead of quietly billing storage forever. The same APIs that cover VMs and Kubernetes cover databases, which means your Terraform and GitOps pipelines can request a database as part of an application stack rather than as a side request.
The gotchas that cost a weekend
First, the license. DSM is a VCF Advanced Service billed separately. Confirm the entitlement before you design a catalog around it, because the database tile is gated by licensing, not configuration. Second, engine support through the self-service portal trails the appliance. Early DSM builds with VCF Automation exposed only Postgres provisioning through self-service even when the appliance supported more; SQL Server 2022 became consumable through the integration with DSM 9.1. The mistake teams make is reading the DSM appliance feature list and promising tenants an engine the self-service path does not yet offer. Verify the engine on your exact VCF Automation and DSM build, in a test org, before it goes in the catalog.
Third, the namespace-backed model means databases run on VKS, so VKS health is now database health. A Supervisor or VKS problem is no longer just a container problem. Fourth, air-gapped sites must repoint both the bundle and the image at a local registry or the Supervisor Service install stalls with no obvious error. None of these are hard once you know them. All of them are quiet, which is worse.
What I'd do
If the license is in hand and you run an All Apps organization, turn on database self-service. It is one of the few VCF Automation features where the payoff is immediate and measurable: routine database tickets stop reaching your DBAs. My recommendation is to lead with Postgres, because it is the most mature self-service engine and it doubles as the pgvector store for private AI, and to use a namespace-backed policy if your tenancy already runs on Supervisor namespaces. When would I not do this yet? If you have no project quotas and no lease or backup policy in place. Stand those up first, then publish the database tile. Database self-service without governance is just a faster way to accumulate unmanaged state. Get the guardrails right and this is the part of the catalog tenants notice first. Which engine and size belong in your first Data Service Policy?
References
- VMware Data Services Manager 9.1: Automating the Modern Databases (Broadcom)
- Using Data Services Manager with VCF Automation as a provider (Broadcom TechDocs)
- VCF Automation Infrastructure Resource Policy overview (Broadcom)
- Installing and configuring DSM with VCF Automation integration (vrealize.it)
- Configuring SQL Server with VCF Automation and DSM 9.1 (Cormac Hogan)
About The Author
