noukuSAN (block storage over Fibre Channel or iSCSI) and object storage (content-addressed, HTTP-API-driven, S3-compatible) solve different problems, and the decision between them for a mission-critical workload should follow from access pattern and consistency requirements, not from a general preference for "cloud-native" or "proven enterprise" infrastructure. Getting this wrong doesn't usually mean the system is unusable — it means paying a latency or consistency tax that shows up under load, exactly when a mission-critical workload can least afford it.
Two Different Abstractions, Not Two Tiers of the Same Thing
SAN presents storage as raw block devices — a server sees a LUN and can format it, mount a filesystem on it, and issue reads/writes at the block level, same as it would to a local disk. The network (Fibre Channel or iSCSI) is transparent to the application; from the OS's perspective it's just a disk. This gives you POSIX filesystem semantics, low and predictable latency, and support for random-access read/write patterns that expect strong consistency — the write you just issued is visible to the next read, full stop.
Object storage presents data as immutable-by-convention objects addressed by key, accessed over an HTTP API (PUT/GET/DELETE, S3-compatible in most implementations), with metadata attached at the object level rather than encoded in a directory structure. There's no block-device abstraction and, depending on the implementation, no guarantee that a write is immediately visible to every subsequent read from every location — many object stores are built around eventual consistency for cross-region replication, though this has narrowed significantly in modern implementations for same-region reads.
Treating these as two points on a single "which storage tier" spectrum is the first mistake. They're different abstractions with different consistency guarantees, and the right choice depends entirely on what the workload's access pattern actually requires.
The Real Decision Variable: Consistency and Latency Requirements, Not Capacity
Choose SAN when the workload needs:
- Low, predictable, sub-millisecond-class latency for random I/O — transactional databases, high-frequency logging, anything where the application is issuing many small reads/writes and blocking on each one.
- Strong read-after-write consistency as a given, not something the application has to work around.
- POSIX filesystem semantics — an application that expects to open a file, seek within it, and write to an arbitrary offset, rather than replacing a whole object.
Choose object storage when the workload needs:
- Massive horizontal scale for largely write-once, read-many data — backups, media assets, log archives, data lake ingestion — where the access pattern is "fetch this whole object" rather than "modify part of this file in place."
- Built-in durability and geographic replication without managing that at the infrastructure layer yourself.
- API-driven access from many distributed clients, where an HTTP-based interface is a better fit than requiring block-level network access.
The mistake that shows up most often in mission-critical contexts is putting a transactional, latency-sensitive workload on object storage because it's cheaper per gigabyte and "everything's moving to object storage anyway" — and then discovering under load that the consistency model and per-request latency characteristics aren't what a transactional system needs. The inverse mistake — running a large write-once archival dataset on SAN because it's "the proven enterprise choice" — is less catastrophic but wastes budget on low-latency block storage for data that will never benefit from it.
Failure Domains Are Different, and That Matters for "Mission-Critical"
For a workload where downtime or data loss is genuinely costly, the failure domain of the storage layer is as important as its performance characteristics. SAN failure domains are typically bounded by the storage array and fabric — redundant controllers, multipathing across fabric switches, RAID or equivalent at the array level. The failure modes are well understood and the mitigations (multipathing, array-level replication, snapshots) are mature.
Object storage failure domains are usually bounded by the storage service's own replication and durability design — data is typically stored across multiple nodes and often multiple availability zones as a baseline behavior, which is a genuinely different (and for many failure scenarios, stronger) durability posture than a single SAN array, even a redundant one. But that durability is against object loss, not against the application experiencing elevated latency or eventual-consistency artifacts during a partial outage. A mission-critical decision has to evaluate both dimensions — durability of the data, and consistency/availability behavior of the access path — rather than treating "durable" and "fast and consistent" as the same property.
Cost Comparisons That Miss the Point
Per-gigabyte cost comparisons between SAN and object storage are common and mostly beside the point for mission-critical workloads, because the workloads that belong on each aren't substitutable. Comparing the cost of storing a transactional database's working set on object storage versus SAN isn't a real option — the database needs block semantics and low latency, and object storage's cost advantage doesn't matter if the workload can't run there without a redesign. The comparison that's actually useful is total cost including the engineering cost of the wrong fit: a transactional workload forced onto object storage semantics requires application-level work (caching layers, consistency workarounds) to compensate, and that engineering cost routinely exceeds whatever was saved on raw storage pricing.
Hybrid Is Usually the Right Answer, Not a Compromise
Most mission-critical systems of any real size use both, deliberately, for different parts of the same system: SAN (or increasingly, NVMe-oF for lower latency at similar semantics) for the transactional working set — the database, the active-state layer the application depends on for consistent low-latency access — and object storage for everything downstream of that: backups, archived transaction logs, media or document assets referenced but not transactionally updated, and data lake ingestion for analytics that doesn't need transactional consistency.
Treating this as a binary choice for the whole system is the underlying error behind most of the mismatches above. The right framing is per-workload, per-access-pattern — not "which storage architecture is our standard," but "what does this specific data's access pattern and consistency requirement actually need."
Route Each Workload to the Tier That Matches It
The decision isn't SAN-versus-object-storage as a single infrastructure choice — it's a per-workload evaluation of what the access pattern and consistency requirement actually demand, repeated for every distinct data flow in the system. Standardizing on one tier for the whole architecture is rarely a technical call; it's usually an organizational default dressed up as one.