DAS vs NAS vs SAN: Storage Architecture Explained

Storage architecture is chosen once and constrains everything afterwards: how servers share data, what happens when one fails, and how the system grows. The three approaches solve different problems and are frequently compared as though one is simply better.

DAS: directly attached

Storage connected directly to one server — drives in the chassis, or an external enclosure connected by SAS.

Advantages. Simplest, cheapest per terabyte, lowest latency, and nothing between the server and its drives. No network to configure, no shared infrastructure to fail.

Limitations. The storage belongs to that server. If the server fails, the data is unavailable until it is recovered or the drives are moved. Capacity cannot be reallocated to another machine without physical work, and stranded capacity is common — one server full while another sits half empty.

DAS suits single-server workloads, boot volumes, backup targets attached to a backup server, and any situation where sharing is not required. It remains the right answer far more often than architecture discussions suggest.

NAS: file-level sharing

A device on the network presenting shared folders over file protocols. Clients mount a share and work with files.

Advantages. Multiple machines access the same data simultaneously with permissions handled centrally. It runs over standard Ethernet with no specialist infrastructure. Straightforward to deploy and administer.

Limitations. The file protocol adds overhead, so it is generally not appropriate for workloads expecting block storage — databases and virtual machine disks in particular, though some platforms support it.

NAS suits shared documents, home directories, media libraries, general file serving, and archive tiers.

SAN: block-level sharing

A dedicated storage network presenting block storage to servers. A server sees what appears to be a locally attached disk and formats it with its own filesystem.

That distinction is the whole point. Because the server sees blocks rather than files, it can run anything that expects a local disk — databases, virtual machine datastores, boot volumes.

Advantages. Shared block storage is what makes virtualisation clustering work: multiple hosts access the same datastore, so a virtual machine can move between them or restart elsewhere when a host fails. Capacity is allocated centrally and reallocated without physical work.

Limitations. Cost and complexity. A SAN means dedicated infrastructure, redundant paths, and expertise to design and run. It is also a shared dependency — a SAN problem affects everything attached to it, which is why redundancy is designed in rather than added.

SAN suits virtualisation clusters, databases needing shared or failover storage, and environments where central allocation across many servers matters.

The distinction that actually matters

File-level versus block-level, rather than which is newer or faster.

File-level means the storage device owns the filesystem and hands out files. Good for sharing documents between many clients.

Block-level means the storage device hands out raw capacity and the server owns the filesystem. Necessary for anything that expects a local disk.

This is why "can I put my virtual machines on the NAS" is a real question rather than a preference. It depends on whether the platform supports that file protocol for datastores — and where it does, performance characteristics differ from block storage.

Where the transport fits

SANs run over different transports, and the choice affects cost and complexity more than capability.

Fibre Channel is a dedicated storage network with its own switches and adapters. Mature and predictable, and it remains in place in many enterprises. Legacy FC arrays are also why Fibre Channel drives stay in demand long after the platform stopped being sold.

iSCSI carries block storage over standard Ethernet. Cheaper and simpler because it uses existing networking skills and equipment, though it should run on separate network infrastructure rather than sharing with general traffic.

SAS connects a shared enclosure directly to a small number of servers — simpler than a full SAN and appropriate for two or three hosts.

Drive selection differs by architecture

A practical point that affects ordering.

Storage arrays frequently use different drives from servers of the same manufacturer, with different part numbers and firmware. HPE MSA drives are not ProLiant drives, and fitting the wrong one produces a drive the array will not accept. Our MSA guide covers this specifically.

NetApp goes further, formatting disks with non-standard sector sizes so a standard drive is rejected outright.

The rule holds across architectures: order against the part number of a drive already fitted, not the manufacturer and capacity. Our compatibility guide lists this by platform.

Choosing

Does more than one server need the same data at the same time? If no, DAS is simpler and cheaper, and that is a legitimate answer rather than a compromise.

If yes, do the workloads need file access or block access? Documents and shares mean NAS. Virtual machine datastores, databases and anything expecting a local disk mean block storage.

If block, how many hosts and how critical? A few hosts can use shared SAS. Many hosts, or clustering requirements, mean a SAN — iSCSI where cost matters, Fibre Channel where the environment already runs it.

Then size capacity backwards from usable requirements, since RAID overhead and unit conversion both reduce it considerably. Our capacity guide covers the arithmetic.

Common questions

Tell us how many hosts need the data and what workloads run on it, and we will help size the architecture and the drives.