"Storage" isn't one thing, and treating it like one thing is a common source of both overspending and underperformance. There are three fundamentally different storage architectures in general enterprise use, each built for a different access pattern, and most real environments need more than one of them at once. This article covers how SAN, NAS, and object storage each work, what they're actually good at, and how to match architecture to workload instead of defaulting to whatever's already in place.
The three storage architectures
SAN (block storage) presents raw block-level storage over a dedicated storage network, typically using Fibre Channel or iSCSI. To the connecting server, a SAN volume looks and behaves like a local disk — the server's operating system formats it and manages a filesystem on top of it directly. Because the connection is low-latency and purpose-built for storage traffic, SAN is the standard choice for workloads that need fast, consistent, high-performance access to structured data: databases and VM datastores are the two most common examples, both of which are highly sensitive to storage latency.
NAS (file storage) presents storage as a shared filesystem, accessed over a standard network using file-sharing protocols like SMB (common in Windows environments) or NFS (common in Linux/Unix environments). Unlike SAN, NAS storage is inherently shareable — multiple users and systems can access the same files and folders concurrently without each needing its own dedicated connection to the underlying disks. This makes NAS the natural fit for shared user drives, department file shares, and general-purpose file storage where the priority is straightforward, concurrent access rather than raw low-latency performance.
Object storage stores data as discrete objects, each bundled with metadata and accessed through an API over HTTP rather than through a traditional filesystem or block interface. It's designed for massive scale and durability rather than low latency, and it's the native storage model behind most cloud platforms. Object storage is well suited to unstructured data, backups, archives, and cloud-native applications that are built to talk to storage via API rather than mounting a drive.
| Architecture | Access model | Best fit |
|---|---|---|
| SAN (block) | Raw block storage over Fibre Channel/iSCSI, formatted by the connecting server | Databases, VM datastores — latency-sensitive structured data |
| NAS (file) | Shared filesystem over SMB/NFS | User drives, department file shares — general concurrent file access |
| Object storage | Discrete objects with metadata, accessed via API/HTTP | Unstructured data, backups, archives, cloud-native apps — scale over latency |
Matching architecture to workload, not defaulting to one
The most common structural mistake in storage planning is standardizing on a single architecture for everything, because it's simpler to manage one platform than three. That simplicity is real, but it comes at the cost of paying for capability the workload doesn't need, or — worse — under-serving a workload that genuinely needed something different.
A production database put on general file storage, or a large archive of unstructured historical records kept on expensive low-latency SAN capacity, are both examples of architecture and workload mismatched in opposite directions: one under-serves performance-sensitive data, the other over-spends protecting data that doesn't need it. The right approach starts from the workload's actual requirements — how latency-sensitive is it, does it need concurrent shared access, how large and how structured is the dataset, what's the real cost tolerance — and picks the architecture that matches, rather than starting from "which platform do we already have" and forcing every workload onto it.
Most real environments legitimately run more than one storage architecture
It is not a sign of poor planning to run SAN, NAS, and object storage simultaneously — it's usually a sign that storage decisions are being made per workload rather than by default. A database on SAN, a shared drive on NAS, and backups on object storage in the same environment is a common and often correct combination.
Storage architecture and virtualization
Storage architecture choices interact directly with virtualized infrastructure. VM datastores — the storage location where virtual machine disk files actually live — are typically placed on SAN specifically because hypervisors and the workloads running on top of them are sensitive to storage latency and I/O performance in ways that file or object storage generally can't match at the same consistency. See Virtualization Fundamentals for how the hypervisor layer depends on the storage layer beneath it.
Storage architecture also shapes backup and recovery design. Object storage's durability and scale characteristics make it a common target for backup repositories and long-term retention, while SAN and NAS are typically where production data actually lives day to day — see the Backup Strategy Guide for how backup destinations are chosen relative to the production storage they're protecting.
Common mistakes
- Running latency-sensitive workloads on the wrong architecture. Object storage is built for throughput and scale, not low latency — putting a transactional database on it produces performance problems that look like application issues but are actually a storage architecture mismatch.
- Over-provisioning expensive SAN capacity for data that doesn't need it. Large volumes of infrequently accessed or unstructured data — old project files, archival records — kept on SAN capacity costs significantly more than the same data on object storage, without a performance benefit that data actually needs.
- Treating all three as interchangeable. SAN, NAS, and object storage solve different problems; standardizing on one to reduce platform count is a legitimate simplification tradeoff, but it should be a deliberate decision, not a default nobody examined.
- No capacity planning per architecture. Growth on shared drives (NAS), database volumes (SAN), and backup/archive repositories (object) tends to happen at different rates — planning capacity as one undifferentiated pool tends to miss the one that's actually about to run out.
FAQ
Which storage architecture is cheapest? Object storage is generally the cheapest per unit of capacity, followed by NAS, with SAN typically the most expensive — but cost per unit isn't the right comparison in isolation, since each is solving a different performance requirement. The right question is cost relative to the workload's actual needs, not cost alone.
Can the same physical storage system provide more than one of these? Yes — many modern storage platforms present block, file, and sometimes object access from the same underlying hardware ("unified storage"), which can simplify management while still letting different workloads use the access method suited to them.
Does moving to the cloud eliminate the need to think about storage architecture? No — cloud platforms offer the same three architectures (block, file, object) as distinct services with different performance and cost characteristics, so the same matching discipline applies; the decision doesn't go away, it just moves to a different environment.