Glossary

Object Storage vs. NAS

Object storage and NAS are two ways of holding unstructured data that differ in how applications reach it. NAS — network attached storage — presents a filesystem over NFS or SMB: a hierarchy of directories, mounted by the operating system, where a program can open a file and write to the middle of it. Object storage presents a flat namespace over an HTTP API: data is written and read as whole objects identified by a key, with no directories and no mount point.

It is tempting to read this as a generational story, with object storage as the modern replacement for the ageing filer. That is not what happened. Object storage displaced NAS for a specific set of workloads — backup targets, archives, data lakes, cloud-native applications — and left the rest alone, because the two are answers to different questions. Most enterprises of any size run both, and will keep running both.

The useful framing is not which architecture is better but what the application on top of it expects. Two questions settle most cases: can the application be pointed at an HTTP endpoint instead of a mount point, and does it need to modify data in place? Everything else in this comparison is downstream of those.

What NAS is

A NAS system is a file server reached over a network. Clients mount an export using NFS (predominantly in Linux and Unix environments) or SMB (predominantly Windows), and from that point the storage behaves like a local disk: paths, directories, permissions, timestamps, byte-range reads and writes, and locks.

That last set is what makes NAS valuable and hard to replace. The filesystem contract lets an application open a file, seek to an offset, write a few bytes, and close it — without rewriting anything else. It lets two processes on different machines coordinate through locks. It lets a backup agent walk a directory tree and read modification times. Decades of software was written against those guarantees, and most of it has no idea what storage it is sitting on.

The architecture is usually a controller pair or small cluster fronting a set of disk shelves, with capacity added by attaching more shelves or deploying another system alongside. Data protection is typically RAID or a vendor equivalent, and the filesystem metadata — the directory tree itself — lives in a structure that one system is responsible for maintaining.

What object storage is

Object storage organizes data into buckets that hold objects, each identified by a key. There is no directory hierarchy: a key like 2026/q1/report.pdf is one flat string, and the folder-like browsing that tools display is produced by asking the API to group keys by prefix and delimiter. Access is over HTTP, in practice via the Amazon S3 API, which has become the default interface for storing unstructured data at scale — see S3 compatible storage for what that entails.

Objects are written and read whole. A PUT replaces the object; there is no equivalent of writing forty bytes into the middle of a four-gigabyte object and leaving the rest untouched. In exchange, each object carries an extensible set of user-defined metadata, protection is handled by replication or erasure coding across many nodes rather than by RAID within an enclosure, and the namespace has no structural reason to stop growing.

The absence of a directory tree is the point. There is no single structure whose maintenance limits how many items the system can hold, and no tree to walk. That is what allows an object store to scale in a way a filesystem does not, and it is also the source of every capability object storage lacks.

The differences that decide the choice

Read that table as one trade rather than seven. Object storage gives up the filesystem contract — in-place writes, locking, POSIX semantics — and gets a namespace that scales, metadata it can carry, and an access method that works across a wide-area network. NAS keeps the contract and accepts the ceiling that comes with it.

Where NAS runs out of room

NAS does not fail at scale so much as get progressively more expensive and more operationally demanding. The recurring pressures:

• The directory tree becomes the bottleneck. Filesystem metadata operations concentrate on a structure that has to stay consistent. Directories holding millions of entries slow down, and anything that walks the tree — backup, indexing, antivirus, capacity reporting — takes progressively longer as file counts grow.
• Backup windows stop closing. A nightly job that has to traverse hundreds of millions of files spends most of its time on metadata rather than data, and eventually the traversal alone outlasts the window.
• Rebuild times grow with drive capacity. RAID reconstruction on high-capacity drives takes long enough that the exposure window during rebuild becomes a real risk calculation rather than a formality.
• Capacity fragments into islands. Growth by adding filers means each has its own free space, its own hot spots, and its own upgrade cycle. Rebalancing is a migration project, and someone has to decide which share lives where.
• Geographic distribution is bolted on. Multi-site file access is typically achieved with replication or caching products layered on top rather than by the storage architecture itself.

None of this argues against NAS for the workloads that need it. It argues against using NAS as the default destination for everything, which is how most organizations arrive at a petabyte of filer capacity holding data nobody has opened in three years.

Where object storage runs out of room

The gaps are the inverse, and they are structural rather than matters of implementation quality:

• No in-place modification. Changing one field in a large object means rewriting the object. For append-heavy or frequently-edited data — database files, VM images, active project files — the write amplification is disqualifying.
• No locking. There is no mechanism for two writers to coordinate. Concurrent writes to the same key resolve as last-write-wins; versioning preserves the loser but does not prevent the collision.
• Per-request overhead punishes small objects. Every operation is an authenticated HTTP request. Workloads dominated by very small reads and writes spend a large fraction of their time on protocol rather than payload, which is why object storage feels slow for exactly the access patterns filesystems handle well.
• Listing at scale is a real cost. Enumerating keys in a bucket holding tens of millions of objects is a paginated operation whose performance varies substantially between implementations, and applications that list before they read will feel it.
• Legacy applications cannot use it directly. Anything that expects a mount point needs either a code change or a gateway, and the gateway brings its own considerations.
• A higher latency floor. Object storage is built for throughput and durability at scale, not for the microsecond-range response times transactional workloads assume.

Matching the workload to the architecture

Most placement decisions are unambiguous once the two questions from the top are applied:

The pattern across the table is that object storage wins where data is written once and read whole, and NAS wins where data is edited in place or shared between concurrent writers. When a workload sits genuinely in between, it is usually two workloads that have been described as one.

The middle ground, and where it leaks

Because most estates need both, a category of products exists to bridge them: file gateways that present NFS or SMB and store the data as objects underneath, and tiering tools that move inactive files off a filer to an object store while leaving a stub in place so the original path still resolves.

These work, and for offloading cold data from an expensive filer they work very well — the data was not being edited anyway. The caution is that a gateway does not change what is underneath it. Object semantics still apply to the objects, so anything the filesystem contract promises has to be emulated by the gateway, and the emulation is where the surprises live. Worth asking directly, of any vendor:

• Which POSIX semantics are actually enforced, rather than accepted and approximated? Byte-range locking in particular.
• What happens to an in-place write — is it a read-modify-write of the whole object, and what does that do to throughput on large files?
• If both a file interface and an object interface are offered, is the same data reachable through both at the same time, or is the file layer a separate path onto the same platform? Both designs are legitimate; they are not the same thing, and marketing language tends to blur them.
• On a conflicting write from each side, which one wins, and is the loser recoverable?

The answers vary enormously between products, and none of them are visible in a proof of concept that only reads and writes whole files.

How Scality approaches it

Scality's two platforms sit on different sides of this line, deliberately. RING presents native file access over NFS and SMB alongside the S3 object API on a single platform, with the file layer built on top of the underlying object store — the practical effect being that existing file-based applications can use the capacity immediately while newer applications address the same infrastructure over S3, and the migration between them happens on the organization's own timeline rather than as a precondition. RING also includes NAS Archiver, which assesses access patterns on existing tier-1 NAS and moves inactive files to RING using a stub-based model, so the data stays online at its original path while leaving the filer to serve what is still active. The premise it rests on is that most filer capacity holds data nobody touches — Scality's own figure is that two-thirds of data on primary storage goes untouched.

ARTESCA is S3 object storage only, aimed at immutable backup and recovery targets rather than at general-purpose file serving.

The evaluation advice is the same one to press on any vendor, Scality included: establish which interfaces are native to the platform and which are provided by a gateway in front of it, and get a specific answer on whether a given dataset is meant to be reachable through both interfaces concurrently or through one at a time. That distinction determines how the system behaves on the day two applications disagree, which is the day it matters.