Block, File, and Object Storage

You have just traced a familiar path: a filename is resolved through namespace and metadata until a location is found for its bytes. That picture is useful, but it can make every storage system look like a filesystem with a different price tag. It is not. The next design decision is more fundamental: what contract should the application receive for naming, changing, and sharing durable data?

By the end of this lesson, you can:

• classify a workload by its naming, mutation, sharing, and coordination needs;
• choose block, file, or object storage by the contract it provides; and
• defend that choice by naming one benefit, one trade-off, and one operational signal.

Idea in one sentence: Block, file, and object storage are contracts that decide how an application may name, mutate, share, and recover durable data.

A design review with three kinds of data

Imagine a team operating a course platform. It has three new storage requests:

1. Its relational database needs space for pages, indexes, and a write-ahead log.
2. Several report jobs and analysts share a directory of CSV exports; existing tools open paths, rename files, and append status logs.
3. The video pipeline stores original uploads, transcoded renditions, thumbnails, and versioned backup archives.

Someone proposes a tidy-sounding rule: “Use one storage product for everything. Bytes are bytes.” The intuition is understandable. At the lowest level every choice eventually retains bits. But the applications do not ask for identical operations. A database wants to control layout and update small regions. The report workflow wants a common path-based namespace. The media archive mostly wants named blobs written once, read many times, and replaced as complete versions.

If the team chooses only by capacity, benchmark headlines, or the product the company already knows, it will later rebuild missing semantics in application code. The database may be forced to replace whole blobs for a page update. The reports may invent a directory service on top of object keys. The archive may inherit locking and namespace coordination it never needed. The problem is not that one of the technologies is “bad”; it is that the promised interface does not match the work.

Core Insight

Storage categories describe an interface, not a ranking. A useful first comparison asks four questions:

This table is a model, not a promise that every product behaves identically. Vendors differ in consistency, snapshots, replication, performance, and API details. The durable design question comes first: which operations must be natural rather than awkward?

Block: mutable space, with meaning above it

Block storage presents addressable durable space. A client or an operating system can read and write locations on a volume; a filesystem, database, or other layer supplies the higher-level meaning. The block layer does not inherently know that some range represents course.db, a directory entry, or a user’s video. It only exposes locations and bytes.

database engine or filesystem
        ↓ decides layout and meaning
block volume
        ↓ addressed ranges
durable bytes

For the platform database, that control is valuable. The database needs to update a page, flush log records according to its durability rules, and organize its own data structures. It may use ordinary files on a local filesystem that itself sits on a block device; the important point is still that the database relies on efficient mutable storage underneath, not on a remote content catalog. A block device does not remove the need for filesystem or database logic. It pushes naming, metadata, concurrency policy, and recovery semantics upward.

The benefit is control. The trade-off is responsibility: if multiple machines need one shared logical namespace, raw blocks alone do not provide it. Giving the same volume to several independent writers without a coordination-aware layer is not a shortcut to shared files; it can corrupt data. Block is therefore not synonymous with “fast,” “simple,” or “best for databases.” It is a lower-level contract whose fit depends on what the layer above is prepared to manage.

File: paths and shared filesystem meaning

File storage exposes the model from the preceding lesson directly: names, directories, permissions, metadata, and file operations. A report job can open /exports/2026-07/completion.csv; an analyst can list the directory; a publisher can write a temporary file and rename it into place. The storage contract supplies a shared namespace that users and legacy tools already understand.

/exports/2026-07/completion.csv
        ↓ path lookup and metadata
file handle / extents
        ↓
underlying durable bytes

This is why the report workflow is a good file-storage candidate. Its work is expressed as files and paths, and several participants must discover and coordinate around those names. The value is not merely that a file service can hold CSV bytes. It is that it can make paths, directory operations, permissions, and familiar tooling part of the contract.

That convenience has a cost. The service must maintain namespace metadata and coordinate operations that touch it. Busy directories, many tiny files, permission checks, locks, and rename-heavy workflows can make metadata behavior an important operational concern. File storage is a poor default for a massive archive merely because people can browse it like folders: a workload that only uploads and retrieves immutable blobs may pay for rich file semantics it does not use.

Object: named blobs with an API-shaped boundary

Object storage treats a stored unit as an object addressed by a key, accompanied by object metadata. A client commonly creates an object with a PUT, retrieves it with a GET, and creates a new version or replacement when its contents change. The exact consistency and versioning rules vary, so read the service contract before designing a protocol. The central distinction is that the interface is for named blobs, not ordinary in-place editing through a shared filesystem handle.

media/lecture-42/source-v3.mp4
        ↓ key lookup
object metadata + complete blob
        ↓
durable, often replicated content

The platform’s videos and backups align well with this model. A transcoder can publish renditions/42/1080p-v5.mp4; a player can retrieve that key; a retention policy can treat an old backup as a complete version. The application can use descriptive key prefixes, but media/lecture-42/ is not automatically a POSIX directory with directory locking, atomic rename, or inherited permissions. It is a naming convention unless the service explicitly says otherwise.

Object storage often makes broad distribution, lifecycle management, and large collections of content easier to operate. Its trade-off is missing file-style behavior. An application that needs frequent tiny random writes, append-in-place, or collaborative pathname operations must either choose a different contract or carefully build and test the missing coordination itself. Calling objects “files in the cloud” hides this cost.

Work the choice from constraints, not labels

Return to the design review. The team can make the decision auditable by writing the workload constraints before choosing a technology.

Notice that this does not say “database = block, reports = file, media = object” forever. A database might run on managed local files; a report product might deliberately publish completed CSVs as objects; an object store can have a filesystem gateway. The reusable reasoning is to identify the operations that are correctness-critical. If the database requires a particular flush or random-write behavior, test that contract. If a report publisher relies on rename visibility, confirm that behavior. If readers should never see a half-published video, publish immutable versioned keys and move a small pointer only with semantics you understand.

Check: A build job produces a 2 GB artifact once, gives it a versioned name, and thousands of workers only download it. It never requires in-place editing or a shared directory listing. Which contract is the best starting point?

Think first, then reveal.

Answer: Object storage. The workload is a named, whole-content artifact with fan-out reads. File storage could work, but its shared path and mutation semantics are not the main requirement. Confirm how publication, versions, access control, and lifecycle behave before relying on them.

Check: Two application servers must update the same database volume. Is attaching an ordinary block volume to both servers enough to make that safe?

Think first, then reveal.

Answer: No. A block volume presents ranges of bytes, not a coordinated multi-writer database protocol. Safety depends on a layer designed for those writers: for example, a clustered filesystem or a database replication/failover design. Sharing a device does not create agreement about who may change which bytes.

Make the trade-offs operational

A storage choice remains a hypothesis until you can observe its failure modes. The signals differ because the contracts move responsibility to different places.

• For block-backed workloads, watch latency and error behavior at the volume boundary, but also the filesystem or database metrics above it: queueing, flush time, checkpoint pressure, and application-level recovery errors. A healthy device does not prove the database’s durability protocol is correct.
• For file workloads, watch namespace and metadata pressure: operation latency for opens, creates, renames, listings, lock contention, small-file growth, and hot directories. Bulk byte throughput can look fine while users wait on path operations.
• For object workloads, watch request latency and error rates, object-size distribution, retry behavior, version/lifecycle accumulation, and hot key or prefix patterns where the service documents them. Track transfer and retrieval cost too when those shape the architecture.

These are not universal dashboards. They are prompts to trace the operation you actually depend on. If a publish workflow writes report.tmp then renames it, measure and test that workflow. If a media worker publishes a new version then updates a manifest, observe the manifest protocol. In the next lesson, caching will add another complication: a successful read may come from several layers, so apparent storage behavior is not always a direct device read.

Common design mistakes

“Object keys give me folders.” Key prefixes make a useful organizational convention, but they do not by themselves provide directory semantics. Treat them as names in an API until the documented contract proves more.

“Block storage is a shared filesystem.” A filesystem can be built on blocks, but it is a separate layer that maintains names and metadata. Multi-host sharing also needs explicit coordination; never infer it from attachment alone.

“File storage is always easier.” It is easier when paths and shared file operations are the problem. For immutable artifacts, a richer contract can create metadata load and operational coupling without adding value.

“Durable means the application is safe.” Durability is only one part of a protocol. A system must still decide what version is visible, how writers coordinate, what happens after a partial failure, and what recovery boundary it promises.

Practice: write the decision record

For each new workload below, choose a first storage contract. State the required operations, one trade-off you accept, and one signal you would monitor.

1. A progress database records frequent small updates and must control when acknowledged records survive a crash.
2. A course-packaging tool and a human editor both use a directory tree of templates, drafts, and renamed releases.
3. An archive stores signed lecture packages that are never edited after publication but must remain retrievable by version for years.

Model answer: (1) Start with a block-backed mutable substrate because the database needs controlled small updates and a known durability path; accept that database and filesystem layers own higher semantics, and monitor write/flush latency plus recovery failures. (2) Start with file storage because shared paths and rename-oriented tooling are the core interface; accept namespace and metadata coordination, and monitor create/rename/list latency and hot directories. (3) Start with object storage because immutable, versioned package retrieval is the core operation; accept API/key rather than file semantics, and monitor retrieval errors, lifecycle/version growth, and publish-manifest correctness.

The important part is not memorizing the mapping. If a constraint changes—say the package editor now needs collaborative in-place edits—you should revisit the contract rather than force the new behavior through the old one.

Resources

• [BOOK] Operating Systems: Three Easy Pieces — Focus: Relate filesystem interfaces to the lower-level storage they organize.
• [DOC] Ceph documentation — Focus: Compare how one distributed platform exposes block, file, and object interfaces without treating them as interchangeable.
• [BOOK] Designing Data-Intensive Applications — Focus: Connect an interface choice to application-level consistency, replication, and recovery trade-offs.

Key Takeaways

1. Choose a storage contract from the operations that must be natural: naming, mutation, sharing, and coordination.
2. Block storage gives mutable addressed space; file storage adds shared filesystem meaning; object storage serves named blobs through an API boundary.
3. Semantic fit reduces application work, but every choice has a trade-off and a distinct set of operational signals.