How many HCI nodes?
vSAN vs Nutanix vs Azure Local.

It’s the greater of two numbers: the capacity-bound node count (enough usable storage after the platform’s resiliency overhead and reserves) and the compute-bound node count (enough CPU and RAM after the hypervisor and any controller VM), then raised to the platform’s minimum host count and plus one for N+1 resilience. This calculator computes all of that for vSAN ESA, Nutanix and Azure Local from one workload and shows which dimension binds — because a capacity-heavy cluster can strand CPU, and vice-versa.

Because they protect data differently. vSAN ESA uses adaptive RAID-5/6 erasure coding (space-efficient, but 4+1 only unlocks at six hosts); Nutanix replicates data (RF2 ≈ half the raw, RF3 ≈ a third, and reserves a rebuild node); Azure Local offers mirror (two/three-way), 2-node nested resiliency (25%), or dual parity whose efficiency scales with node count and media. Same usable-TB target, different raw needed — so different node counts. The tool makes those trade-offs explicit rather than hiding them behind one vendor’s optimistic defaults.

You can — and you should confirm the final design with one — but the vendor sizers (Nutanix Sizer, the vSAN ReadyNode Sizer) are login-gated and single-platform, so you can’t easily put the three side by side early in a decision. This is a free, no-login, vendor-neutral first-pass to frame the conversation, especially for teams leaving VMware and weighing where to land. We deliberately size it as a deterministic raw→usable engine with cited constants, not a black box.

vSAN ESA: raw × compression, minus a log-structured-filesystem overhead (~13%) and metadata (~10%), minus a reserve (a fixed ~5% operations reserve plus ~1/N host-rebuild reserve at four or more hosts), divided by the RAID factor. Nutanix: raw ÷ replication factor, minus a reserved rebuild node, kept below the 95% Stargate cap. Azure Local: (raw pool − repair reserve of one capacity drive per node up to four) × the resiliency efficiency fraction. Every constant is from the vendor’s own documentation.

They’re real but workload-dependent, so the tool treats data reduction as a planning band you set (default ×1.0 = assume none), never a baked-in vendor claim. vSAN ESA is compression-only (no dedupe); Nutanix erasure coding compresses cold data; Azure ReFS dedup is a separate, workload-dependent layer. Set a conservative ratio you can defend, size the hardware for that, and treat any extra savings as headroom — not the plan.

Yes, on the compute side. Nutanix runs a Controller VM on every node that reserves vCPU and a hard RAM allocation (indicatively ~10 vCPU / 32 GB — confirm against a current Nutanix sizer, as it’s version- and feature-dependent), which the tool subtracts from usable compute. vSAN ESA and Azure Local S2D are in-kernel, so their overhead is smaller but non-zero. This is why the same node can host slightly fewer VMs on Nutanix than on vSAN.

The resiliency multipliers, reserves, host minimums and the sizing method are taken from Broadcom/VMware TechDocs, the Nutanix Bible and Microsoft Learn, and cross-checked in an adversarial fact-check pass (July 2026). The maths is deterministic and test-covered. Node and drive specs are your editable estimates, and two items are flagged to confirm at quote — the exact Nutanix CVM reservation and vSAN ESA per-device RAM scaling. A Servnet architect validates the final design against the vendor sizer before you buy.