The question I still get asked in storage design sessions is whether to start a new VCF 9 cluster on vSAN OSA or ESA. In 2025 that was a real debate. In 2026 it mostly is not, and this post is about why, plus the narrow case where OSA still earns its place.

Two architectures, one default

OSA, the Original Storage Architecture, is the two-tier model you know: disk groups with a dedicated cache device fronting capacity devices. ESA, the Express Storage Architecture, is single-tier and all-NVMe. Every device serves both performance and capacity, there is no disk-group construct, and a new log-structured filesystem underpins it. In VCF 9, ESA is the recommended default for all new vSAN deployments and hardware refreshes. OSA is not deprecated, and it remains fully supported, but the platform is built around ESA now.

ESA versus OSA at a glance

Dimension	vSAN ESA	vSAN OSA
Tiering	Single-tier, all-NVMe, no disk groups	Two-tier, cache + capacity disk groups
Resilience vs performance	RAID-5/6 at near-mirror performance	Trade-off: RAID-1 fast, RAID-5/6 slower
Compression	Always on (cluster service)	Optional, per-policy
Hardware	ESA ReadyNode, NVMe TLC required	Broader HCL, SAS/SATA SSD or hybrid
Performance vs OSA	2x to 5x on the same hardware (Broadcom)	Baseline
9.1 additions	Auto-RAID, global dedup, cross-mount	Maintained, not the focus of new features
Best for	Any new build or refresh	Reusing existing non-ESA hardware

Why ESA changes the resilience math

The big idea in ESA is that it kills the old OSA trade-off between mirroring and erasure coding. In OSA you chose RAID-1 for speed or RAID-5/6 for space efficiency and accepted the performance hit. ESA gives erasure-coded space efficiency at near-mirror performance, so you stop paying for resilience with latency. The capacity math is the reason it matters: FTT=1 RAID-1 mirroring costs 2x the raw capacity, RAID-5 costs about 1.33x on a 3+1 layout and 1.5x on the 3-to-5-host 2+1 layout, and RAID-6 4+2 costs about 1.5x while still tolerating two failures. Same resilience, far less capacity burned. RAID-5/6 erasure coding is all-flash only, which ESA always is. Compression moved from a per-policy toggle to an always-on cluster service. VCF 9.1 layers on Auto-RAID, a system-managed resilience model where clusters of 6 or more hosts default to FTT=2 with RAID-6, 3 to 5 hosts use FTT=1 with the 2+1 RAID-5 scheme, and the policy rule is removed so you stop hand-tuning it.

---

The hardware objection is gone

The historical argument for OSA was cost: ESA needed certified NVMe ReadyNodes and felt expensive to start. The November 2025 ReadyNode revision changed that. The profiles were consolidated and the floor dropped to 16 cores and 128 GB RAM per host, with up to a 67% RAM reduction and 33% core reduction on storage-cluster profiles. Minimums can be as low as 2 NVMe devices per host, though 3 to 4 is sensible so the 2+1 RAID-5 secondary resilience works without buying more disks. RAM scales with device count, roughly 128 GB at 12 devices up to 256 GB at 24. The space efficiency angle also feeds licensing: vSAN bundles 1 TiB of raw capacity per VCF core, and ESA always-on compression plus 9.1 global deduplication directly stretch that included entitlement, as detailed in the licensing breakdown.

When OSA still makes sense

Exactly one scenario: you are reusing existing two-tier, SAS-SSD, or hybrid hardware that is not ESA-ReadyNode-certified, and you want to keep that gear in service to end of life. OSA is the preserve-your-investment path. It is not the build-something-new path. If you are buying any new disks, you are buying NVMe TLC, and that means ESA. The placement of these clusters in the wider design is in the reference architecture deep-dive.

Sizing ESA hosts without overbuying

The ReadyNode profiles after the November 2025 revision collapse to three sizes each for the two families you will actually use: vSAN-HCI-SM, MED, and LRG for hyperconverged clusters, and vSAN-SC-SM, MED, and LRG for storage clusters. RAM scales with device count, roughly 128 GB at 12 devices, 192 GB at 18, and 256 GB at 24. A practical greenfield starting point is 4 NVMe devices per host on PCIe Gen5, or 6 on Gen4, which gives you enough spindles for the 2+1 RAID-5 scheme to land its secondary resilience without a later disk purchase. The two-device floor exists, but I would not build production on it, because you lose the option to tolerate a device failure during a rebuild. Read-Intensive TLC is supported for most use cases, so you are not forced into the most expensive Mixed-Use drives unless your write profile genuinely demands them.

Disaggregation and cross-mounting in 9.1

The disaggregated model, once branded vSAN Max and now called vSAN storage clusters, separates storage hosts from compute and requires ESA. VCF 9.1 made it materially more flexible. A storage cluster can now be shared across vCenter boundaries the way a traditional array is, and a compute-only cluster can mount both OSA and ESA datastores. The old cross-mount limit that stopped an ESA datastore being mounted to an OSA cluster is gone in 9.1. This matters for design because it lets you stand up a dense ESA storage tier and feed it to multiple compute clusters without forcing every cluster onto the same architecture overnight, which is a far gentler migration story than a forklift.

A note on the vendor numbers

Broadcom quotes 2x to 5x performance over OSA on the same hardware, global deduplication up to 8x in 9.1, and lower TCO than external arrays. Treat the headline ratios as vendor claims rather than independent benchmarks, because real numbers depend on your block size, working-set locality, and how compressible your data actually is. The directional point holds regardless: ESA removes the resilience-versus-performance trade-off and the always-on data services stretch your bundled TiB. Just size from your own workload profile, not from a slide.

Choose ESA for any new build

For any VCF 9 greenfield build or hardware refresh, choose vSAN ESA. Full stop. You get erasure-coded RAID-5/6 at mirror-class performance, always-on compression plus 9.1 global dedup that multiplies your bundled per-core TiB, and hardware minimums low enough that the old cost objection no longer holds. On 9.1, leave Auto-RAID enabled and let the cluster manage resilience. OSA is now strictly a legacy-preservation choice: pick it only to keep existing non-ESA-certified hardware running to end of life. Do not start a new OSA cluster in VCF 9. If you are repurposing an existing fleet, what share of your current vSAN hardware is ESA-ReadyNode-certified today?

References

• VCF Blog: Auto-RAID in vSAN for VCF 9.1
• VCF Blog: Lower Hardware Requirements for vSAN
• VCF Blog: Announcing vSAN in VCF 9.1

About The Author