KubeDB on VMware VKS: Validated Database-as-a-Service for VCF

vSphere Kubernetes Service (VKS) gives your teams Kubernetes clusters on demand. Databases usually still come through a ticket queue. KubeDB closes that gap, and it is now validated on VKS. A production-ready database, with high availability, TLS, backups and monitoring built in, becomes one YAML object or a few clicks in a console, on the VMware Cloud Foundation (VCF) you already run.

Hyperscaler database services work only inside their own cloud, with their own APIs, tooling and hard-to-predict costs, and they’re often ruled out for regulated, sovereign or air-gapped sites. KubeDB runs on any conformant cluster, so hybrid estates get the same database API everywhere, with VCF as the validated home for the data they keep on premises.

AppsCode and VMware published the validated stack as a reference architecture, and KubeDB is listed among Broadcom’s Kubernetes software partners .

  • Validated: VCF 9.0, VKS 3.7 and KubeDB v2026.10.12; all eight PostgreSQL high-availability tests passed
  • What you get: 30+ database engines, automatic failover, backups, day-2 OpsRequests and monitoring
  • Start here: reference architecture · step-by-step guide

KubeDB adds the database layer on top of VKS and VCF

Each layer handles its own failures: vSphere HA and VKS replace failed nodes, KubeDB promotes a standby when a database member fails, and backups leave the cluster for an S3-compatible store.

VKS runs the clusters, KubeDB runs the databases

VKS provides CNCF-conformant Kubernetes clusters governed with the same vSphere tools and policies teams already use for VMs. For databases, that foundation matters: vSAN storage policies decide how each volume is protected, NSX isolates and load-balances database traffic, vSphere HA and vSphere Zones keep the nodes available, and vSphere Namespaces with vCenter Single Sign-On control who can create clusters. The vSphere administrator keeps those controls; application teams get self-service inside them.

KubeDB adds one Kubernetes custom resource per database engine and operators that automate the whole database lifecycle. It covers more than 30 engines, including PostgreSQL, MySQL, MongoDB, Redis, Kafka and Elasticsearch. The KubeDB Platform builds on the operators with a web console for self-service provisioning and day-2 operations, plus multi-cluster management across VKS clusters and clusters elsewhere. Multi-cluster management is built on Open Cluster Management (OCM) : a hub cluster registers VKS and other clusters as spokes and manages their databases from one console.

The KubeDB Platform console showing the VKS cluster’s feature sets and nodes

From the console, teams create databases, run backups and day-2 operations, and open each database’s Grafana dashboard without writing YAML.

AreaVKS on VCF providesKubeDB adds
PlatformConformant Kubernetes clusters with automated provisioning and upgradesDatabase operators for 30+ engines
StoragevSAN storage policies exposed as StorageClasses through vSphere CSIA persistent volume per member, online volume expansion, storage autoscaling
NetworkingNSX and VPC networking, load balancing, AntreaPrimary and standby Services, per-database network policies
SecurityvSphere Namespaces, vCenter Single Sign-On, cert-managerDatabase TLS, credential rotation, RBAC on database resources
AvailabilityvSphere HA, vSphere Zones, automatic node replacementReplication, automatic failover, self-healing
Data protectionvSphere CSI volume snapshotsEncrypted, database-aware backups with point-in-time recovery (KubeStash)
OperationsSupervisor services and VKS standard packagesDay-2 changes as OpsRequests, autoscaling, per-engine dashboards

A day-2 change, such as scaling or a TLS rotation, is a small YAML object (an OpsRequest) that the operator runs step by step and records. Teams get an audit trail instead of a runbook. Because databases and OpsRequests are plain Kubernetes objects, they can live in Git and be applied by Argo CD or Flux like any other workload.

What we validated

All eight tests passed on a three-member, TLS-enabled PostgreSQL 18.3 cluster running on VKS. The lab cluster used the same Kubernetes release, ClusterClass and vSAN policy as the production design, on smaller nodes.

LayerValidation environment
VCFVMware Cloud Foundation 9.0, vCenter Server 9.0.2
VKS3.7, Kubernetes v1.36.2, Ubuntu 24.04 nodes
Nodes1 control plane (best-effort-medium), 3 workers (8 vCPU / 32 GB)
StoragevSAN ESA, default RAID-5 policy
NetworkNSX with VPC networking, one vSphere Zone
KubeDBv2026.10.12 with KubeStash, cert-manager, kube-prometheus-stack
TestWhat we didOutcome
ProvisioningApplied one Postgres object with 3 replicasReady with one primary, two standbys, three vSAN volumes
FailoverDeleted the primary podA standby was promoted; the old primary rejoined as a standby; writes kept working with no client change
Volume expansionOnline, 50Gi to 100GiAll volumes grew with no pod restarts
Horizontal scaling3 to 4 members and backReplica count changed with the database available
Vertical scalingRaised CPU and memoryRolling restart, standbys first
TLS rotationRe-issued server certificatesNew certificates, data intact
Backup and restoreKubeStash to S3, restored into a new databaseEvery row restored, including rows written after the failover
MonitoringPrometheus and the KubeDB Grafana dashboardAll six targets up, dashboard populated

The KubeDB Datastore view after the tests: pg-ha and the restored pg-restored, both Ready

Duration of each validation test

During failover, a standby was promoted in 31 s and the old primary rejoined as a standby 47 s after the failover. Rolling operations, such as vertical scaling and TLS rotation, restart standbys first and finish with a switchover, so they take longer but keep the database online.

How failover works: each member runs a pg-coordinator sidecar that handles leader election. When the primary fails, the coordinators promote a standby and KubeDB points the primary Service at it, so clients reconnect to the same address. With an even member count, KubeDB adds a small arbiter pod so the election always has a quorum.

Similar patterns apply to the other engines: the installer enables Elasticsearch/OpenSearch, Kafka, MariaDB, MongoDB, MySQL, PostgreSQL, Pgpool and Redis/Valkey by default. This validation covered PostgreSQL.

Sizing tip: when you run the full KubeDB Platform, use three guaranteed-large control plane nodes, as the reference architecture recommends.

Try it

There are two install paths. Both need a license tied to the cluster’s kube-system namespace UID, which you can request from the AppsCode License Server .

kubectl get ns kube-system -o jsonpath='{.metadata.uid}'
PathInstallsUse it when
A. AppsCode installer (recommended)KubeDB, KubeStash, cert-manager, monitoring, the KubeDB Platform web console and multi-cluster management, as Flux HelmReleases on the VKS helm-controller add-onYou want the full self-service platform
B. Helm chartsKubeDB and KubeStash onlyYou only need the operators

Path B in two commands:

helm install kubedb oci://ghcr.io/appscode-charts/kubedb \
  --version v2026.10.12 --namespace kubedb --create-namespace \
  --set-file global.license=./license.txt --wait --burst-limit=10000

helm install kubestash oci://ghcr.io/appscode-charts/kubestash \
  --version v2026.10.12 --namespace stash --create-namespace \
  --set-file global.license=./license.txt --wait --burst-limit=10000

For air-gapped sites, mirror the AppsCode images to Harbor and override the image registry in the chart values.

Then a highly available PostgreSQL cluster on vSAN is one object:

apiVersion: kubedb.com/v1
kind: Postgres
metadata:
  name: pg-ha
  namespace: demo
spec:
  version: "18.3"
  replicas: 3
  standbyMode: Hot
  storage:
    storageClassName: vsan-esa-default-policy-raid5
    accessModes: ["ReadWriteOnce"]
    resources:
      requests:
        storage: 50Gi
  deletionPolicy: Delete

Day-2 changes are objects too. This OpsRequest grows every volume online from 50Gi to 100Gi, as in the validation run:

apiVersion: ops.kubedb.com/v1alpha1
kind: PostgresOpsRequest
metadata:
  name: pg-ha-expand
  namespace: demo
spec:
  type: VolumeExpansion
  databaseRef:
    name: pg-ha
  volumeExpansion:
    mode: Online
    postgres: 100Gi

Read more

Try it on your own VCF estate. Contact AppsCode for a proof of value.

Support

To speak with us, please leave a message on our website .

To receive product announcements, follow us on X .

To watch tutorials of various Production-Grade Kubernetes Tools Subscribe our YouTube channel.

If you have found a bug with KubeDB or want to request for new features, please file an issue .


TAGS

Ready to Transform Your
Cloud Native Journey?

Join hundreds of companies using AppsCode products and services to build, deploy, and manage production-grade Kubernetes applications.

Enterprise Support

24/7 Monitoring

Expert Consultation

Trusted by Fortune 500 companies and innovative startups worldwide