SAN vs NAS: Enterprise Storage Architecture Explained

Local disk works fine until it doesn't. The moment you're running more than a handful of servers, local storage turns into a liability: every host becomes a single point of failure, capacity planning turns into a per-server spreadsheet nightmare, and migrating a VM or rebuilding a database server means physically moving data instead of just repointing a connection. Enterprise storage architecture exists to decouple compute from the disks underneath it.

That's where storage area networks (SAN) and network-attached storage (NAS) come in — two very different answers to the same problem. Both centralize storage so multiple servers can share it, but they present that storage to the network in fundamentally different ways, and picking the wrong one for a workload creates performance and reliability problems that are painful to unwind later. This article breaks down how each actually works, where hyperconverged infrastructure (HCI) fits into the modern picture, and how to decide what belongs where.

Block storage vs file storage: the core difference

Everything about SAN and NAS design traces back to one architectural decision: what layer of abstraction gets exposed to the client. A SAN delivers block-level storage — raw, unformatted blocks of storage capacity that the connecting server's operating system sees and treats exactly like a local disk. The server partitions it, formats it with a filesystem (NTFS, ext4, VMFS, whatever it needs), and manages it directly. The SAN itself has no concept of files, folders, or permissions — it just serves numbered blocks on request.

NAS, by contrast, delivers file-level storage. The NAS device owns the filesystem, and clients talk to it over a network file-sharing protocol, requesting specific files and directories rather than raw blocks. The NAS handles the filesystem logic, metadata, permissions, and locking on its own, and hands back files, not disk sectors.

This distinction cascades into everything else: latency characteristics, protocol choice, how many hosts can safely touch the same data at once, and which workloads each is suited for. A database engine wants direct, low-latency block access it fully controls. A team file share wants concurrent, permission-aware access from dozens of users at once. You cannot swap one architecture in for the other without consequences.

A SAN hands a server an empty disk over the network; a NAS hands it a folder.

How a SAN actually works

A SAN is a dedicated network — separate from your regular LAN in traditional designs — connecting servers to shared storage arrays. Two protocols dominate: Fibre Channel and iSCSI.

Fibre Channel (FC) runs over purpose-built optical fabric using HBAs (host bus adapters) instead of regular NICs, switched through dedicated FC switches. It's low-latency, high-throughput, and predictable — the tradeoff is cost and operational complexity, since it requires its own cabling, switching hardware, and administrative skill set separate from IP networking. iSCSI takes the opposite approach: it encapsulates SCSI commands inside IP packets and runs over standard Ethernet, meaning you can build a SAN using the switches and NICs you already understand. It's cheaper and simpler to deploy, but shares bandwidth and congestion characteristics with whatever Ethernet fabric it rides on unless you isolate it properly.

Storage on a SAN is carved up into LUNs (logical unit numbers) — logical slices of the array's physical capacity presented to a specific host or cluster as if they were dedicated disks. Zoning (on FC fabrics) and equivalent access-control lists on iSCSI restrict which initiators (servers) can see which LUNs, which is your primary security and blast-radius control on a shared array — get zoning wrong and you can accidentally expose one server's LUN to another, with catastrophic filesystem-corruption potential.

Multipathing is the other pillar of SAN design: each host maintains multiple independent physical paths to the same LUN (multiple HBAs or NICs, multiple switches, multiple array controller ports), with multipathing software handling failover and load balancing across them. A SAN without redundant paths has a single point of failure baked into the architecture regardless of how resilient the array itself is.

This combination — dedicated low-latency fabric, direct block access, and the host owning its own filesystem — is exactly why SANs are the default for databases and VM cluster storage. A database engine issuing thousands of small, latency-sensitive IOPS needs a storage layer that doesn't add file-protocol overhead on every read and write, and hypervisor clusters need shared block storage so VMs can be live-migrated between hosts without copying data.

How NAS actually works

NAS operates at the file layer using network file-sharing protocols, primarily NFS (Network File System, dominant in Linux/Unix environments) and SMB/CIFS (Server Message Block, dominant in Windows environments). Modern deployments increasingly use NFSv4, which folds in stronger security (Kerberos-based authentication), stateful locking, and better firewall friendliness compared to the older NFSv3.

Because the NAS device owns the filesystem, it's also responsible for the coordination problems that come with many clients touching the same data: file locking (preventing two users from corrupting a file they're both writing to simultaneously), permissions enforcement, and concurrent access arbitration. This is the fundamental capability a block device does not have — a SAN LUN mounted by two hosts simultaneously without a clustering filesystem will corrupt data, because neither host knows the other is writing. A NAS is built for exactly this multi-writer scenario.

That makes NAS the natural fit for shared file storage: home directories, team drives, department shares, and content repositories where dozens or hundreds of users and applications need simultaneous, permission-scoped access to the same file tree. It's also common for media and backup workloads where sequential throughput matters more than the ultra-low random-IO latency a database needs.

Where hyperconverged infrastructure (HCI) changes the picture

Hyperconverged infrastructure takes a different architectural bet entirely: instead of a dedicated storage array that compute nodes reach over a SAN, HCI pools the local disks inside each compute node using a software-defined storage layer, replicating and distributing data across the cluster so any node can serve any VM's I/O. There's no separate storage array to rack, cable, zone, or manage — storage and compute scale together as you add nodes.

The tradeoffs are real in both directions. HCI collapses SAN fabric, dedicated array hardware, and much of the associated operational overhead into a single, more homogeneous cluster — fewer moving parts, faster time-to-deploy, and a management plane that treats compute and storage as one resource pool. For many mid-sized virtualization estates this is a genuine operational win. But it also couples storage and compute scaling together: if you need more storage capacity but not more compute (or vice versa), you're still buying whole nodes, which is less efficient than a SAN where you scale the array independently of the servers attached to it. HCI clusters also depend heavily on node-to-node network bandwidth and latency for replication traffic, so the "network" doesn't go away — it just moves from a dedicated FC fabric to the HCI cluster's east-west interconnect, which needs to be sized just as seriously.

HCI isn't a strict replacement for SAN or NAS so much as a third architectural option that trades some scaling flexibility and peak performance ceiling for operational simplicity — a good fit for standardized virtualization platforms and edge/ROBO deployments, less obviously a fit for workloads with extreme or unpredictable storage-scaling requirements decoupled from compute.

A real-world example

Consider a mid-sized company running a VMware cluster that hosts both its transactional database tier and its general-purpose file shares. The infrastructure team doesn't put everything on one storage platform — they split it deliberately.

The database VMs — an OLTP system backing the order-management platform — sit on SAN-backed block storage over iSCSI, with LUNs presented to the hypervisor cluster and multipathing configured across two independent Ethernet fabrics for redundancy. The database engine needs consistent, low-latency block I/O and the ability to live-migrate between hosts without touching the underlying data, which is exactly what shared block storage with a clustering-aware filesystem provides.

Team file storage — shared drives, department folders, home directories for a few hundred employees — runs on a separate NAS appliance serving SMB shares to Windows clients and NFS exports to a handful of Linux build servers. The NAS handles user-level permissions through Active Directory integration and manages locking automatically when multiple people have the same spreadsheet open.

They didn't consolidate onto one platform because the workloads have opposite requirements: the database needs a small number of hosts doing high-IOPS, low-latency block access to storage they fully control at the filesystem level, while the file shares need hundreds of concurrent users doing lighter, permission-gated file access where the storage device manages coordination on their behalf. Forcing either workload onto the other's architecture would mean either exposing a raw LUN to hundreds of untrusted concurrent writers (a corruption risk) or routing latency-sensitive database transactions through file-protocol overhead they don't need.

Common mistakes to avoid

Putting latency-sensitive database workloads on NAS instead of SAN. File-protocol overhead (NFS/SMB round-trips, filesystem arbitration on the NAS side) adds latency that a database engine issuing high volumes of small random I/O will feel immediately. NAS can serve databases in specific supported configurations, but as a default architecture choice, transactional workloads belong on block storage.

Undersizing SAN fabric bandwidth and multipathing. Teams often size the storage array carefully and then treat the fabric connecting hosts to it as an afterthought — a single HBA, a single switch, or insufficiently sized ISLs (inter-switch links) turn a resilient array into a system with one physical dependency that takes everything down when it fails. Multipathing isn't optional redundancy; it's a required part of the design, not a bolt-on.

Ignoring IOPS requirements and sizing storage on capacity alone. A storage array sized purely on "how many terabytes do we need" routinely gets deployed under workloads that need far more random-read/write performance than the underlying disk count and RAID/erasure-coding scheme can deliver. Capacity and performance are separate sizing exercises — spinning-heavy arrays that look fine on a capacity spreadsheet can become a severe IOPS bottleneck the moment a real database or VM cluster lands on them.

Frequently asked questions

Can a single storage array serve both SAN and NAS protocols?
Yes — many modern arrays are "unified storage," exposing the same underlying disk pool as both block LUNs (over FC/iSCSI) and file shares (over NFS/SMB) from one platform. This simplifies management but means SAN and NAS workloads can compete for the same backend disk and controller resources, so capacity and performance planning still needs to account for both sides.

Is iSCSI "good enough" to replace Fibre Channel entirely?
For most mid-sized enterprise workloads, yes — modern Ethernet (10/25/100GbE) with properly isolated, dedicated storage VLANs and jumbo frames closes much of the historical latency gap. Fibre Channel still holds an edge in the most demanding, latency-critical environments and in shops that already have deep FC operational expertise, but it's no longer the automatic choice it once was.

Does HCI eliminate the need to understand SAN and NAS concepts?
No — HCI abstracts away the physical SAN fabric, but the underlying concepts (replication, data locality, network bandwidth for storage traffic, failure domains) still apply inside the HCI cluster's software-defined layer. Engineers who understand SAN and NAS architecture troubleshoot and design HCI deployments more effectively than those who treat it as a black box.

SAN, NAS, and HCI aren't competing for the same job — they're different architectural answers shaped by whether a workload needs raw block access it controls itself, coordinated multi-user file access, or a simplified, converged operational model. The engineers who get enterprise storage design right aren't the ones who pick a favorite; they're the ones who map each workload's actual I/O and access pattern to the architecture built for it, and size for performance as rigorously as they size for capacity.