Data grows faster than budgets. Each year the average organisation multiplies its stored volume, and the temptation to "buy more disk" soon hits a wall of cost, latency and management overhead. Designing scalable storage is not about accumulating capacity; it is about placing each piece of data on the right medium, with the appropriate level of redundancy, along a growth path that does not require taking the service offline. This article covers the three major storage architectures — block, file and object — the automatic tiering that connects them, and the durability mechanisms that distinguish genuinely reliable storage from storage that only appears reliable until the first failure.
Block, file and object: three models, three use cases
Block storage (SAN) exposes raw volumes over protocols such as iSCSI or Fibre Channel. The operating system sees them as local disks and applies its own file system on top. It is the model with the lowest latency and highest IOPS, ideal for transactional databases and virtual machines. Its weakness: it scales poorly horizontally, and a volume is typically mounted by a single host at a time.
File storage (NAS) serves folder and file hierarchies over NFS or SMB/CIFS. Multiple clients share the same file system, with POSIX permissions or ACLs. It is the natural model for shared directories, user home folders and applications that expect path-based access. It scales better than block storage, but hierarchical metadata becomes a bottleneck at large scale.
Object storage (compatible with the S3 API) stores data as flat objects identified by a key, with no real folder hierarchy, rich metadata and HTTP-based access. It is the model that underpins the cloud: extremely high durability, practically unlimited horizontal scaling and low cost per gigabyte, in exchange for higher latency and eventual or strong consistency depending on the provider. It is ideal for backups, media archives, data lakes and large-scale cold data.
Comparison of storage architectures
| Characteristic | Block (SAN) | File (NAS) | Object (S3) |
|---|---|---|---|
| Unit | LBA block | File in a tree | Object + key |
| Protocol | iSCSI, FC, NVMe-oF | NFS, SMB | HTTP / S3 API |
| Latency | Very low | Low to medium | Medium to high |
| Scaling | Vertical | Limited horizontal | Massive horizontal |
| Typical use case | Databases, VMs | Shared resources | Backup, data lake, media |
| Cost per GB | High | Medium | Low |
Automatic tiering: hot data at the top, cold data at the bottom
Not all data has the same value or is accessed with the same frequency. Automatic tiering moves data between storage classes according to access patterns. In practice, several layers coexist: hot on NVMe/SSD for what is being read and written right now; warm on SAS or standard S3 for what is accessed occasionally; and cold/archive on tape or deep archive classes for what is almost never touched but must be retained for compliance. Lifecycle policies automate the transitions: an object that has had no reads for 30 days drops to a cheaper class, and after 180 days moves to archive.
The savings are real, but tiering requires deliberate design: retrieving data from a deep archive tier can take hours and incur retrieval costs. Moving to archive what might be needed urgently is a mistake as costly as keeping on NVMe what nobody ever reads.
Horizontal scaling and software-defined storage
The key difference between storage that scales and storage that runs out of room lies in the growth model. Vertical scaling (scale-up) adds disks to an existing array until its controllers are exhausted: it is simple but has a physical ceiling and a single point of failure. Horizontal scaling (scale-out) adds nodes to a cluster, distributing both capacity and performance: each node contributes disk, CPU and network, so the system grows linearly without a service interruption. This is the model used by modern distributed systems (Ceph, MinIO and commercial scale-out arrays) and the reason why object storage can grow to exabyte scale.
On top of this sits Software-Defined Storage (SDS), which decouples storage logic from proprietary hardware and runs it on commodity servers. SDS allows mixing vendors, automating provisioning through policies and orchestrating volumes declaratively — particularly relevant in container environments, where the CSI (Container Storage Interface) in Kubernetes provisions persistent volumes on demand. The trade-off is that complexity shifts from hardware to software and to the people managing it: a poorly dimensioned distributed cluster, particularly with an undersized internal network or incorrect replication factor, performs worse than a well-tuned traditional array.
Durability: RAID, erasure coding and the 3-2-1 rule
Reliability means the data survives hardware failure. RAID protects against disk failure: RAID 6 tolerates two simultaneous disk failures, but the rebuild times for large-capacity disks are long enough to increase the risk window significantly. This is why modern object storage uses erasure coding, which fragments each object into k data fragments plus m parity fragments and distributes them across nodes; a 10+4 scheme tolerates four simultaneous failures with a capacity overhead far lower than triple replication.
No RAID configuration is a backup. The 3-2-1 rule remains the gold standard for reliability: three copies of the data, on two different types of media, with one copy off-site. Against ransomware, the variant 3-2-1-1-0 has become common: one immutable or air-gapped copy and zero errors verified in restore tests. A backup that has never been restored is not a backup — it is a hope.
Performance: IOPS, throughput and latency are not the same thing
Sizing storage correctly requires distinguishing three quantities that are frequently confused. IOPS (input/output operations per second) measure how many requests the system handles; they matter for workloads with many small, random operations, such as a transactional database. Throughput (MB/s) measures the volume of data transferred; it dominates for large sequential file workloads such as backups or video streaming. And latency (milliseconds) measures the response time of each individual operation — which is what users and applications actually perceive. A system can have very high IOPS yet feel slow if its tail latency (p99 percentiles) spikes under load.
The most expensive sizing mistake is optimising for the wrong quantity: buying very high-throughput disks for a database that needed IOPS and low latency, or vice versa. The correct design therefore starts by characterising the actual I/O pattern of each application — block size, read/write ratio, randomness and peak load — before choosing the medium. Caching on SSD/NVMe in front of slower tiers, and separating workloads into distinct pools, allow the database and the backup repository to coexist without one starving the other of resources.
Compliance: encryption, retention and GDPR
Reliable storage is also compliant storage. GDPR requires encryption of personal data at rest and in transit as an appropriate security measure, sets retention periods (data is not kept indefinitely "just in case") and mandates the ability to fulfil the right of erasure — which in object storage with versioning and WORM retention requires explicit design. The immutability that protects against ransomware (Object Lock) can conflict with the right to deletion if the coexistence of both requirements is not planned from the outset. The information security management best practices of the ISO/IEC 27001 family provide the control framework for governing all of this.
Common errors in storage architecture
- Using object storage as a low-latency file system. Consistency and latency characteristics do not match transactional workloads.
- Confusing RAID with backup. RAID protects against disk failure, not against deletion, corruption or ransomware.
- Not testing restores. The "zero errors" requirement of the 3-2-1-1-0 rule only exists if it is verified.
- Tiering without measuring access patterns. Moving to archive data that is actually consulted drives up retrieval costs.
- Ignoring encryption at rest. A lost unencrypted disk is a notifiable breach under GDPR.
Frequently asked questions
NAS or SAN for a database?
SAN (block) for its lower latency and higher IOPS. NAS is better suited to shared file access; some databases run over NFS, but block storage remains the reference option for demanding transactional workloads.
What durability does object storage offer?
Cloud providers commonly advertise "eleven nines" (99.999999999% annual durability) thanks to replication or erasure coding across availability zones. That figure describes the probability of not losing an object due to media failure; it does not remove the obligation to maintain independent backups.
What exactly is automatic tiering?
It is the movement of data between storage classes of different cost and performance based on their access frequency, governed by lifecycle policies that apply the transitions without manual intervention.
Is the 3-2-1 rule still relevant with cloud storage?
Yes, and it has been strengthened. The cloud makes off-site copies easier, but it is still advisable to keep at least one immutable copy and to diversify across providers or media types to avoid dependence on a single point of failure.
Conclusion
Storage ceases to be a capacity problem and becomes a design problem as soon as volumes grow: the right question is not "how many terabytes should I buy?" but "which data lives on which tier, with what level of redundancy and under what lifecycle policy?". A scalable system combines block storage for transactional workloads, file storage for shared resources and object storage for high-volume data, with tiering that reduces the cost of cold data without penalising hot data, and a 3-2-1-1-0 strategy that even survives ransomware — all of it encrypted and with retention periods that comply with GDPR. At Summum Sistemas we design that architecture based on each client's real access patterns, and we verify restores before claiming that the data is safe.