A NAS serves files and a SAN serves blocks. Network attached storage owns the disks and the filesystem, and answers requests for named files over the ordinary network. A storage area network hands a server raw capacity over a dedicated network, and the server puts its own filesystem on it, so the storage behaves like a local disk.
- A NAS is file level, a SAN is block level
- The filesystem lives on the NAS, or on your server
- A SAN volume belongs to one server unless clustered
- iSCSI carries block storage over ordinary Ethernet
- Most performance complaints about a NAS are network complaints
On this page
The distinctionFile storage and block storage
Every difference between these two storage architectures comes from one thing: what level the data is shared at.
A NAS is file level storage. A user says "give me the third quarter report from this folder" and the NAS device finds it, reads it and returns the data.
The NAS owns the disks, owns the filesystem on them, and answers questions about named files. Multiple users can read and write the same share at once, because one storage device is arbitrating access between them.
A SAN is block level storage. A server says "give me blocks 4096 through 4103 of the volume you assigned me" and the SAN returns raw data. A SAN has no idea what a file is.
The server formats the volume itself, with NTFS or VMFS or ext4, and to the operating system it is a local storage device that happens to be far away.
That single difference produces everything else people list. A NAS is simple because the hard part is done for you. A SAN has better performance because there is no file level in the data path and no other host to coordinate access with.
A SAN volume normally belongs to one server at a time, because two systems writing their own filesystems to the same blocks would destroy the data on it. The clustered filesystems that allow shared access are exactly why VMware and failover clusters are the classic SAN workload.
Networks and protocolsHow each one connects
A NAS uses the Ethernet network already in the building. Plug the device into a switch, give it an address, and users reach it over NFS on Linux or SMB on Windows. That is the whole installation. The data shares the same wires as everything else, which is fine at small scale and becomes the performance limit at large scale.
A SAN uses a dedicated storage network. Traditionally Fibre Channel, which is a separate physical network with its own switches, its own cabling and its own adapters in each server, built so that a storage request never queues behind an email. That separation is most of what a storage area network buys and most of what it costs.
The middle ground that changed the market is iSCSI. iSCSI carries the same block level protocol over ordinary Ethernet, so a SAN can be built from switches you already understand. Its performance is below Fibre Channel and more sensitive to a congested network, and for most workloads that does not matter.
A dedicated storage VLAN, or better a dedicated pair of network switches, gets most of the isolation without the separate fabric. Most SANs built in the last decade are iSCSI ones.
The protocols in one place, since they are what the datasheets argue about.
| Protocol | Level | Runs on | Where it fits |
|---|---|---|---|
| SMB | File | Ethernet | Windows systems and user shares |
| NFS | File | Ethernet | Linux systems and hypervisor datastores |
| iSCSI | Block | Ethernet | Most SANs built in the last decade |
| Fibre Channel | Block | Its own fabric | Enterprise arrays, lowest latency |
| FCoE | Block | Ethernet | Fibre Channel without the separate cabling |
| NVMe over Fabrics | Block | Ethernet or FC | Flash arrays, where speed is the point |
The first two are what a NAS speaks. The rest are what SANs speak, and the only one of them a small network is likely to meet is iSCSI.
WorkloadsWhat each one is actually good at
| Workload | Better fit | Why |
|---|---|---|
| Shared department files | NAS | Multiple users on one share, arbitrated for you |
| Home directories and profiles | NAS | Permissions and quotas belong at the file level |
| Backup targets | NAS | Capacity and simplicity beat latency |
| Media and archive | NAS | Sequential, and cheap per terabyte |
| Virtual machine datastores | SAN | Low latency, and the hypervisor wants blocks |
| Database volumes | SAN | Predictable latency, and the database wants raw storage devices |
| Failover clusters | SAN | Shared block access is what the cluster requires |
| Boot from network | SAN | A server boots from a block storage device, not a share |
The pattern is worth naming. If the applications on the other end are users opening files, file level storage is right. If it is an operating system that wants to own a storage device, block level storage is right.
PerformancePerformance, honestly
The claim that SAN performance beats NAS performance is true and usually irrelevant, so it is worth being precise about where the difference actually lives.
Latency, not raw speed, is where the difference is real. A block level request over Fibre Channel completes in well under a millisecond. A file level request over SMB carries protocol overhead, metadata operations and locking, and lands several times higher.
For database applications committing transactions that difference is the whole ballgame. For a user opening a spreadsheet it is invisible, because no human notices a millisecond.
Raw speed is closer than the marketing suggests. A modern NAS device on a 10 gigabit Ethernet link saturates it on sequential reads. If the workload is copying large files, the network is the performance limit and both storage architectures do the same thing.
Concurrent access favors the NAS by design. Multiple users on one share is what network attached storage does. Multiple servers accessing one SAN volume is a cluster configuration, not a default.
The real world answer is that most NAS performance complaints are network complaints, and most are fixed by a dedicated link or a faster switch rather than by buying a SAN.
CostCost, and what people forget
A NAS is one storage device and some disks. A four bay device costs a few hundred, a rack mounted one with redundant controllers costs what a server costs, and the Ethernet network is already there.
A SAN is the storage array, the switches, an adapter in every server, the cabling and the software licenses. It is normal for the network around a SAN to cost as much as the storage devices in it.
Budget for two of everything: the entire point of the architecture is that a single failure does not take the data away from the systems depending on it.
Then there is the cost nobody quotes. A SAN needs somebody who understands zoning, multipathing and LUN masking. That skill is not rare but it is not free, and an unmanaged SAN is a worse outcome than a well managed NAS device.
Scaling and running itScalability and day to day management
How each one grows is a real difference, and it is the question that follows the first one.
A NAS grows by filling it, then by adding another. A network attached storage device has a fixed number of bays. When they are full you replace disks with larger ones or you buy a second device, and now there are two namespaces for users to remember.
Scale out NAS products fix this by presenting multiple devices as one filesystem, and that is the scalability answer worth paying for if the data keeps growing.
A SAN grows by adding shelves. A storage area network was designed for this: capacity is added to the array, presented as new volumes, and the servers see more storage without anything moving. Scaling capacity is the thing SANs are unambiguously better at, and it is why they persist in enterprise environments where data grows steadily and predictably.
Management is the mirror image. A NAS is administered like an appliance: shares, permissions, quotas, snapshots, all in one web interface a generalist can learn in an afternoon.
A SAN is administered like infrastructure: zoning decides which systems can see which storage devices, LUN masking decides which volumes each one is offered, and multipathing decides what happens when a link fails. None of that is difficult, and all of it is specific knowledge that somebody has to hold.
The management difference is what actually decides the purchase in a small team. A storage system nobody understands is a risk, whatever its speed numbers say.
PitfallsWhere people go wrong
Buying a SAN for file shares. A SAN volume is a disk. To give users file access to it, a server has to mount the volume and re-serve the data, which means you bought a SAN and a file server to do a NAS's job.
Putting the storage network on the production switches. iSCSI on the same network switches as everything else works until a backup job saturates a link, and then virtual machines start seeing storage timeouts. Separate the data, physically if possible.
Presenting one volume to multiple servers without a clustered filesystem. Both systems format it, both cache it, and the data is destroyed within minutes. Every hypervisor and cluster product has a specific way to do this, and it is not optional.
Assuming shared storage means backed up. A NAS or a SAN with RAID survives a disk failure. It does not survive deletion, ransomware, or a controller writing corruption to both copies of the data. Shared storage is availability, not backup.
Ignoring the single point of failure that was added. Twenty servers that each had local storage devices now depend on one array. That is usually a net gain, but only if the array has redundant controllers, redundant paths and redundant power, and only if somebody has tested pulling a cable.
Unified and cloudThe middle ground worth knowing
Two things have blurred the line, and both come up in any current conversation.
Unified storage is one array that speaks both, presenting file level shares and block level volumes from the same disks. Most mid range data storage sold today does this, which makes the original question less either or than it used to be.
Hyperconverged infrastructure removes the array entirely, pooling the local storage in each server into one shared pool over the network. It answers the same problem as a SAN and is often the alternative actually being weighed, particularly for virtualization.
Cloud storage is the third option in every current conversation, and it maps onto the same split. A cloud file service is network attached storage somebody else runs, reached over a private link or a VPN. A cloud block volume is a SAN volume somebody else runs, attached to a cloud instance.
Object storage is neither, and is the one genuinely new shape: no filesystem, no blocks, just keys and data, which is why it dominates backup and archive and is wrong for anything that needs low latency access.
The cloud does not remove the question. An enterprise moving to cloud storage still chooses file access or block access for each workload, and pays for the difference. What it removes is the array, the switches and the person who understood the zoning.
Neither changes the underlying distinction. Something is still serving data at the file level or at the block level, and the workload still decides which it wants.
ComparisonNetwork attached storage and a storage area network, on what actually decides it
| Criterion | NAS | SAN |
|---|---|---|
| What it serves | Files | Blocks |
| Who owns the filesystem | The appliance | Your server |
| Network required | The one you have | Usually dedicated |
| Setup effort | Low | High |
| Cost to start | Low | High |
| Latency under load | Higher | Very low |
| Many clients on one dataset | Native | Needs a cluster filesystem |
| Virtual machine datastores | Workable | The standard choice |
| Databases with strict latency | No | Yes |
| Skills needed to run it | General | Storage specific |
Read the first two rows and the rest follows. If the applications on the other end want files, a NAS wins on every practical count. If they want to own a storage device, only a SAN gives them one.
FAQFrequently asked questions
What is the main difference between NAS and SAN?
The level the data is shared at. Network attached storage serves files and owns the filesystem. A storage area network serves raw blocks, and the server puts its own filesystem on them.
Is a SAN network storage?
Yes, but not in the sense people usually mean. SAN network storage is block level storage reached over a dedicated storage network, traditionally Fibre Channel or iSCSI, and a server treats the volume it is given as a local disk and formats it itself.
Network attached storage is the other kind: file level storage over the ordinary network, where the NAS device owns the filesystem and hands out named files.
Is SAN performance better than NAS performance?
On latency, yes, and by a lot. On sequential throughput they are often the same, because both hit the network limit first.
Can a NAS do block level storage?
Many devices can, over iSCSI, which makes them a small SAN. Unified arrays do both properly from the same disks.
Do I need Fibre Channel for a SAN?
No. iSCSI carries block level storage over ordinary Ethernet, and that is what most mid sized SANs use now. Fibre Channel buys isolation and consistent latency.
Can two servers use the same SAN volume?
Only with a clustered filesystem such as VMFS, or a cluster aware configuration. Two ordinary servers formatting the same volume will destroy the data on it.
Which is better for virtual machines?
A SAN, or a NAS device over NFS, which hypervisors also support well. What you should not do is put datastores on an SMB share.
Is a NAS good enough for a small business?
For almost all of them, yes. A network attached storage device with redundant disks and a real backup covers file sharing, backups and light virtualization, with management any generalist can handle.
What is LUN masking?
The storage area network control that decides which servers can access which volumes. Without it every server sees every volume, which is how the two servers one volume disaster happens.
Does RAID on the storage array mean I do not need backups?
No. RAID survives a failed disk. It does not survive deletion, ransomware, or corruption written to every copy of the data at once.
What is unified storage?
One storage system serving both file level shares and block level volumes from the same disks. Most current mid range storage does this.
What about hyperconverged infrastructure?
It pools the local storage in each enterprise server rather than using a separate array. It competes with SANs for the same workloads, and its scalability story is the reason it is usually on the shortlist.
Which of the file protocols should a NAS use?
SMB for Windows systems, NFS for Linux systems and for hypervisor datastores. Serving the same data over both is possible and creates permission problems worth avoiding.
Keep readingRelated concepts
Read next · Addressing What Is a Subnet? A storage network is usually its own subnet, and that separation is most of what it buys. Open this next15 min- Disks and drives · 12 min SSD vs HDD What goes in the array once you have chosen the architecture around it.
- Disks and drives · 10 min MBR vs GPT A SAN volume is a disk to the server, so it gets partitioned like any other.
- Hypervisors · 11 min Hyper-V vs VMware Where the virtual machine datastores actually live, once the hypervisor is chosen.
- Cabling and connectivity · 10 min Cat6 vs Cat6a The cabling that has to carry a storage network, and how far it reaches.
- Containers · 11 min Containers vs VMs What runs on the datastores this storage provides.
- Disks and drives · 11 min RAID 5 vs RAID 10 The redundancy scheme running inside the array, whichever kind you bought.
- Backup · 13 min The 3-2-1 Backup Rule, and What Ransomware Did to It Where the local copy usually lives, and what to buy for it.
- Backup · 12 min Immutable Backups, and the Setting That Decides Whether They Work Where the first copy lands, and what it can and cannot lock.
- Shared storage · 9 min NFS vs SMB, and Why the Clients Decide The two file sharing protocols a NAS speaks, and which clients each one suits.