SDDC stack vs modular Proxmox
VCF bundles several products into one managed package. Proxmox provides equivalent functions, but as a modular, open set of building blocks. Layer mapping:
| Layer | VMware VCF | Proxmox VE 9.2 |
|---|---|---|
| Compute / hypervisor | vSphere (ESXi) | KVM + LXC |
| HCI storage | vSAN | Ceph (built-in) |
| Network & security | NSX | SDN (EVPN/VXLAN) + firewall |
| Operations / automation | VCF Operations, VCF Automation | Prometheus/Grafana + Ansible/Terraform |
| Full-stack lifecycle | VCF Operations (since VCF 9; previously SDDC Manager) | apt + Ansible (pve8to9 only for the 8→9 jump) |
| Backup | paid add-on | Proxmox Backup Server |
Green = a built-in, mature equivalent; amber = achievable, but assembled from separate tools. Below are the details of those amber rows and what is genuinely missing.
The hard gap: zero-downtime FT
This is the most commonly cited real gap. VMware Fault Tolerance (FT) keeps a secondary copy of the VM on a second host and, on host failure, resumes it from the last checkpoint — with no data loss. That is no longer the old lockstep mode. Proxmox has no FT equivalent; it has HA, i.e. automatic restart of the VM on another node (downtime measured in seconds–minutes).
How to cover it in Proxmox:
- Redundancy in the application — an app cluster, database replication (Patroni/Galera), a pair of load balancers. This is the proper HA pattern for critical services anyway.
- HA + fast restart — for most workloads a restart within tens of seconds is perfectly acceptable.
To be fair: even in VMware, FT has significant limits (vCPU cap, performance overhead, no snapshots) and is rarely used in practice — application-level redundancy is usually both cheaper and more resilient.
Networking and micro-segmentation without NSX
NSX is an advanced networking platform: a distributed firewall (micro-segmentation at the VM NIC), L7 rules, NAT/VPN/Load Balancer gateways, multi-site federation. Proxmox covers the foundation — EVPN/VXLAN (overlay, multi-tenant networks) plus a built-in firewall (iptables by default, nftables backend as a technology preview; per-VM rules and groups) — but has no out-of-the-box distributed L7 firewall or service gateways.
How to cover it in Proxmox:
- Micro-segmentation — the Proxmox firewall (per-VM/CT) + security groups and VLAN/VXLAN zones; rules travel with the VM config.
- L7 / NAT / VPN / LB gateways — a virtual NGFW (OPNsense, pfSense) or HAProxy/NGINX and WireGuard/IPsec as dedicated edge VMs.
Operations and automation with open source
The VCF 9 tools — VCF Operations, VCF Automation, VCF Operations for logs and VCF Operations for networks (formerly Aria / vRealize: vROps, vRA, Log Insight, Network Insight) — provide monitoring, capacity planning, self-service and log analytics in one. Proxmox has no single such package — you assemble it from mature, open tools:
- Monitoring and capacity — the built-in external metric server sends data to Graphite, InfluxDB or OpenTelemetry (e.g. InfluxDB + Grafana); for Prometheus + Grafana you add prometheus-pve-exporter (ready-made Proxmox/Ceph dashboards).
- Logs — Loki or an ELK/OpenSearch stack for central analysis.
- Automation and self-service — Terraform (a community provider, for example bpg/proxmox) and Ansible on top of Proxmox's full REST API.
The upside of modularity: you don't pay for features you don't use and you aren't locked into one ecosystem — at the cost of assembling a few components (which we handle during deployment).
SDDC Manager and ISV certifications
- Stack lifecycle — since VCF 9, patching is in VCF Operations and bring-up is in the VCF Installer (validated images). SDDC Manager remains in the stack, without the lifecycle API. In Proxmox you update more simply (
aptand Ansible; thepve8to9script only for the 8→9 jump) — less "magic", but far fewer moving parts to maintain. - ISV certifications — some vendors (SAP, Oracle) certify their products mainly on VMware. On Proxmox this is often a matter of negotiating support terms; KVM is widely supported, but the certification matrix is narrower.
- Self-service / multi-tenant cloud — a VCF Automation equivalent (which is also taking over Cloud Director multi-tenancy) is built in Proxmox from resource pools, RBAC and the API (optionally a custom or third-party portal).
When VCF, and when Proxmox 9.2
With 9.2, most historical "pro-VMware" arguments are gone (DRS, SAN snapshots as a volume chain — still a technology preview, HA rules, SDN). A few specific cases remain:
- Choose VCF when you hard-require: zero-downtime Fault Tolerance, deep NSX micro-segmentation with L7 rules, a certified ISV stack, or a ready self-service cloud (VCF Automation).
- Choose Proxmox VE 9.2 for the other ~95% of cases: no license fees or lock-in, full control, and you cover the gaps above with proven patterns (application redundancy, NGFW, Prometheus/Grafana, Terraform/Ansible).
The best first step is an audit: it usually turns out that of the whole VCF you actually use vSphere + vSAN, while NSX, VCF Operations, VCF Automation and FT touch only a few systems — which are easy to handle differently in Proxmox.
We'll check which VCF features you actually use
We'll audit your environment, identify the VCF features you genuinely rely on, and design their equivalent in Proxmox VE 9.2 — with savings and no vendor lock-in.
⚡ Free consultation → VMware vs Proxmox: TCO analysis