SAN vs NAS: Storage Architectures

By Kokil Thapa | Last reviewed: August 2026

Choosing between SAN and NAS storage architectures determines whether your application scales predictably or bottlenecks under load. While cloud object storage dominates headlines, on-premise and hybrid deployments still rely heavily on this distinction for databases, virtualization, and high-performance file serving. Understanding SAN vs NAS: Storage Architectures is essential for any full-stack developer or technical lead managing infrastructure that must balance latency, throughput, and budget in 2026.

For teams evaluating website development cost in Nepal or planning self-hosted infrastructure, the storage layer often dictates long-term operational expenses more than compute. A misconfigured storage backend causes intermittent application timeouts that no amount of PHP-FPM tuning can fix. In my experience maintaining production Laravel applications and legal-tech portals, storage decisions made during initial setup frequently become the primary constraint eighteen months later when data volumes grow. This guide cuts through vendor marketing to focus on how these architectures actually behave under real application workloads.

How do SAN and NAS differ at the protocol level?

The fundamental difference lies in abstraction. NAS operates at the file system level, presenting directories and files to clients. The NAS device owns the filesystem; clients simply request "open /data/report.pdf". SAN operates at the block level, presenting raw LUNs (Logical Unit Numbers) that the client's operating system formats and manages as if they were local disks. This distinction drives every subsequent architectural decision.

NAS protocols like NFSv4.2 and SMB 3.1.1 handle metadata operations, locking, and permissions server-side. When your Laravel application writes a log file to a NAS mount, the NAS controller decides where physical blocks land. This adds overhead but simplifies multi-client sharing. SAN protocols like iSCSI, Fibre Channel (FC), or NVMe-oF transport SCSI commands over the network. Your MySQL server sees a /dev/sdb device indistinguishable from a local SSD, handles its own filesystem journaling, and issues direct block reads without remote metadata negotiation.

This matters because database engines expect synchronous write guarantees. On NAS, an fsync() call traverses the network stack twice (request + acknowledgment) and depends on the NAS implementation's flush semantics. Some budget NAS devices acknowledge writes before platters commit data, risking corruption during power loss. SAN presents deterministic latency because the host controls the entire write path. For legal-tech portals handling sensitive case documents where data integrity is non-negotiable, this distinction justifies SAN's additional complexity.

When should you choose SAN over NAS for production databases?

Databases represent the clearest SAN use case. PostgreSQL 17 and MySQL 8.4 perform best with predictable sub-millisecond latency and consistent IOPS delivery. SAN excels here because block-level access eliminates filesystem translation overhead and enables storage features like hardware-accelerated snapshots and thin provisioning that integrate with database backup strategies.

Consider a production Laravel application backed by MySQL 8.4 LTS storing e-commerce orders. During peak sales events, query patterns shift from read-heavy catalog browsing to write-intensive order insertion. On NAS, concurrent INSERT statements compete for file locks and metadata updates at the NAS controller, creating tail latency spikes visible in slow query logs. On SAN, each database thread issues blocks directly through the HBA or iSCSI initiator, bypassing shared metadata bottlenecks.

• OLTP workloads: Transactional databases with random 4K-8K read/write patterns benefit from SAN's low queue depth latency. NVMe-oF SANs deliver <100μs latency versus 200-500μs for typical NFS.
• Virtualization boot storms: When 50 VMs boot simultaneously, SAN handles the metadata-intensive VMDK/VHDX access patterns better than NAS, which serializes directory lookups.
• Regulated environments: Legal-tech systems requiring audit trails and WORM (Write Once Read Many) compliance often leverage SAN-based hardware encryption and immutable snapshot policies unavailable on commodity NAS.
• High-availability clusters: Active-passive failover clusters need shared block storage for quorum disks and cluster-aware filesystems like OCFS2 or GFS2, which require SAN.

A common mistake is deploying MySQL on NFS-mounted NAS to simplify backups, then troubleshooting mysterious InnoDB corruption after network hiccups. InnoDB expects POSIX-compliant fsync behavior; many NAS implementations optimize for throughput over strict durability. If you must use NAS for databases, verify your vendor explicitly supports database workloads and test failure scenarios before going live.

How does total cost of ownership compare between SAN and NAS in 2026?

Cost analysis extends beyond hardware purchase price. SAN requires specialized HBAs (£200-400 per server), Fibre Channel switches ($3,000-8,000 per pair), and often proprietary management software licenses. NAS uses standard Ethernet NICs and switches already present in most server rooms. For Nepali businesses operating on NPR-denominated budgets where import duties affect capital expenditure, this difference compounds significantly.

iSCSI and NVMe-over-TCP have narrowed the gap considerably. Modern 25GbE converged networks carry both storage and application traffic, eliminating separate FC fabric costs. For mid-sized deployments (20-100TB), iSCSI SAN on existing Ethernet infrastructure often matches NAS pricing while delivering block-level performance. However, NAS remains cheaper for pure file-serving workloads where you'd otherwise pay for unused block capabilities.

In practice, many organizations I've worked with adopt hybrid approaches: SAN for database LUNs, NAS for application assets and backups. This optimizes spend by matching workload characteristics to appropriate storage tiers rather than forcing everything onto one platform. When advising clients on database-driven website development in Nepal, I typically recommend starting with NAS for development/staging and reserving SAN investment for production databases once traffic justifies the premium.

What are the practical configuration steps for iSCSI SAN on Linux?

iSCSI democratized SAN access by running SCSI over TCP/IP. Here's a production-ready configuration for Ubuntu 24.04 connecting to a TrueNAS or Dell PowerVault target, suitable for hosting MySQL data directories or Laravel storage volumes.

Install and configure the initiator

<!-- Install open-iscsi utilities -->
sudo apt update
sudo apt install open-iscsi multipath-tools -y

<!-- Set initiator name (must be unique across your SAN fabric) -->
echo "InitiatorName=iqn.2026-08.np.kokil:laravel-prod-db01" | sudo tee /etc/iscsi/initiatorname.iscsi

<!-- Discover available targets on storage array -->
sudo iscsiadm -m discovery -t sendtargets -p 192.168.100.50:3260

<!-- Log in to specific target with CHAP authentication -->
sudo iscsiadm -m node -T iqn.2026-08.np.storage:mysql-lun01 -p 192.168.100.50:3260 --login

<!-- Configure automatic login on boot -->
sudo iscsiadm -m node -T iqn.2026-08.np.storage:mysql-lun01 -p 192.168.100.50:3260 -o update -n node.startup -v automatic

Configure multipath for redundancy

Production SAN deployments require multipathing to survive cable failures or controller maintenance. Edit /etc/multipath.conf:

defaults {
    user_friendly_names yes
    find_multipaths yes
}

devices {
    device {
        vendor "TRUE*"
        product "NAS*"
        path_grouping_policy group_by_prio
        path_selector "round-robin 0"
        path_checker tur
        prio alua
        failback immediate
        rr_weight priorities
        no_path_retry 12
    }
}

After configuration, restart services and verify paths:

sudo systemctl restart multipathd open-iscsi
sudo multipath -ll
# Expected output shows multiple active paths in round-robin state
# mpatha (36001405...) dm-0 TRUE,NAS
# size=500G features='0' hwhandler='1 alua' wp=rw
# |-+- policy='round-robin 0' prio=50 status=active
# | `- 6:0:0:1 sdb 8:16 active ready running
# `-+- policy='round-robin 0' prio=10 status=enabled
#   `- 7:0:0:1 sdc 8:32 active ready running

Format the multipath device (not individual /dev/sdX paths) and mount persistently via UUID in /etc/fstab. Never format individual paths directly; doing so creates split-brain scenarios where different filesystem instances corrupt each other during failover events.

How do modern NVMe-oF and software-defined storage change the decision?

Traditional SAN vs NAS binaries blur with NVMe-over-Fabrics and hyperconverged infrastructure. NVMe-oF transports NVMe commands over RDMA (RoCEv2) or TCP, delivering near-local SSD latency across the network. This makes SAN viable for workloads previously considered too latency-sensitive for networked storage, including Redis persistence layers and Elasticsearch indices.

Software-defined storage platforms like Ceph, MinIO, and TrueNAS SCALE further complicate categorization. These systems present unified interfaces: Ceph RBD provides block volumes (SAN-like), CephFS offers POSIX filesystem access (NAS-like), and RGW delivers S3-compatible object storage—all from the same underlying OSD cluster. For teams building custom ERP systems in Nepal that need both transactional databases and document repositories, Ceph eliminates separate storage silos entirely.

However, complexity increases proportionally. Ceph requires careful CRUSH map design, sufficient OSD count for failure domain distribution, and dedicated monitoring. A three-node Ceph cluster providing meaningful redundancy needs ~12 OSDs minimum plus separate MON/MGR nodes. Compare this to a TrueNAS HA pair delivering similar usable capacity with simpler operations. The right choice depends on team expertise and scale thresholds.

NVMe-oF also introduces new networking requirements. RoCEv2 demands lossless Ethernet with PFC (Priority Flow Control) and ECN (Explicit Congestion Notification) properly configured end-to-end. Misconfigured PFC causes head-of-line blocking that manifests as intermittent application hangs worse than traditional TCP retransmissions. NVMe/TCP avoids RDMA dependencies but sacrifices ~20% throughput. Test thoroughly before committing to NVMe-oF in production; the performance gains are real but conditional on correct infrastructure.

Making the Right Storage Choice for Your Workload

The optimal storage architecture emerges from workload analysis, not feature checklists. Map your application's I/O patterns first: measure read/write ratios, block sizes, queue depths, and latency percentiles using tools like fio or iostat before selecting hardware. Database-heavy stacks with strict consistency requirements point toward SAN; content repositories and collaborative environments favor NAS; mixed workloads at scale justify software-defined platforms despite operational overhead.

Budget constraints in markets like Nepal make iSCSI SAN on 25GbE increasingly attractive as a middle ground, delivering 80% of Fibre Channel performance at 40% of the cost. Avoid over-engineering early; many successful production systems start on NAS and migrate specific LUNs to SAN only after profiling identifies storage as the actual bottleneck. When planning infrastructure for your next project or evaluating cloud hosting services in Nepal versus self-hosted options, remember that storage architecture decisions compound over years—choose based on measured requirements, not anticipated ones.

If you're designing storage for a production application and need practical guidance grounded in real deployment experience, reach out to discuss your specific workload. Storage mistakes are expensive to fix after data accumulates; getting the architecture right initially saves significant migration pain downstream.