"vSAN" and "SAN" get used almost interchangeably by IT teams sizing up storage for a virtualisation project, but they're built on opposite ideas: one is a physical appliance your hypervisors talk to over the network, the other pools the disks already sitting inside your hypervisor hosts. Picking the wrong one means paying for capacity or flexibility you don't need — so here's what each actually is, and which fits which environment.
What is a SAN?
A SAN (storage area network) is a dedicated, physical storage appliance connected to your servers over Fibre Channel or iSCSI, presenting block storage that looks like a local disk to whatever's using it — a hypervisor, a database server, an application host. It's a well-understood, decades-old architecture: your compute and your storage are separate boxes, connected over a network.
SANs range from small 4-bay units to dense multi-bay rackmounts, and capacity scales by adding external expansion shelves rather than by adding more compute. QSAN's XCubeSAN and XCubeNXT ranges cover that spectrum, from entry-level dual-controller SANs through to all-flash NVMe arrays, alongside NAS and unified storage for teams that need file as well as block.
What is vSAN?
VMware vSAN is the specific product most people mean when they say "vSAN": VMware's software-defined storage layer, built into vSphere, which pools the local disks across a cluster of ESXi hosts into one shared datastore. There's no separate storage appliance — the storage lives inside the same servers running your VMs, and vSAN handles the replication between hosts so a single host failure doesn't take data with it.
That convenience now comes with licensing strings attached. Since Broadcom's acquisition of VMware, vSAN is sold bundled inside VMware Cloud Foundation (VCF) or vSphere Foundation (VVF) rather than as a standalone add-on, with a 16-core-per-socket minimum per host — see our VMware alternatives shortlist for the current numbers. Architecturally, a fully redundant vSAN cluster also wants three nodes, not two, which rules it out for smaller branch or ROBO sites without over-buying hardware.
That gap is exactly what StarWind VSAN — a separate, unrelated product despite the similar name — is built for. It's software-defined storage that mirrors the local disks of just two servers plus a lightweight witness, giving you HA shared storage without a third full node or VMware's licensing bundle. It also isn't tied to one hypervisor: StarWind VSAN runs under VMware ESXi, Microsoft Hyper-V, Linux KVM and Proxmox VE, which makes it a useful bridge if you're planning to move hypervisors later without re-architecting storage at the same time. Our StarWind vs VMware vSAN comparison goes through the licensing and architecture differences in more detail.
The practical difference
| | SAN | vSAN (software-defined) | |---|---|---| | Where storage lives | Separate physical appliance | Disks inside the hypervisor hosts | | Scaling capacity | Add expansion shelves | Add nodes (and their disks) | | Hardware flexibility | Fixed appliance, storage scales independently of compute | Compute and storage scale together | | Typical minimum footprint | Single appliance | 2 nodes + witness (StarWind) or 3 nodes (VMware vSAN) | | Licensing | Per-appliance / per-capacity | Per-node, often bundled with the hypervisor platform |
Which one fits your business?
If your workloads need predictable, appliance-level performance and you'd rather scale storage and compute independently — or you're already running mixed workloads outside virtualisation, like file shares or backup targets alongside your VMs — a SAN is usually the simpler, more cost-predictable choice. It's also the more mature option if in-house Fibre Channel/iSCSI networking expertise already exists.
If you're consolidating a small site onto two or three servers and want to avoid a separate storage purchase entirely, software-defined storage makes more sense — StarWind VSAN for a 2-node branch office, or VMware vSAN if you're already committed to a 3-node-plus vSphere Foundation deployment. The trade-off is that your storage capacity is now coupled to how many compute nodes you buy.
Many CRS partners actually deploy both: a QSAN SAN as a backup target or file-serving tier, and StarWind VSAN under the production hypervisor cluster for HA compute. See our storage and virtualisation solution pages for how the two combine, or contact us if you want help sizing either option for a specific environment.