vault

Object Block and File Storage Compared

14 min read

Object Block and File Storage Compared

Cloud storage comes in three fundamentally different shapes, and choosing the wrong one is one of the most expensive early architecture mistakes you can make. Object storage (Amazon S3, Google Cloud Storage, Azure Blob) stores data as immutable blobs with metadata in a flat namespace, reached over an HTTP/REST API, engineered for near-infinite scale and extreme durability. Block storage (Amazon EBS, Google Persistent Disk/Hyperdisk, Azure Managed Disks) presents a raw volume — a virtual disk — that you attach to one virtual machine, format with a filesystem, and use for low-latency reads and writes; it is the disk under a database. File storage (Amazon EFS, Google Filestore, Azure Files) offers a shared POSIX or SMB filesystem that many clients mount at once over a network. The distinction is not cosmetic: they differ in access protocol, unit of manipulation, consistency, latency, how many clients can share them, how they scale, and what they cost. This note lays the three side by side, explains why each exists, and gives a decision procedure. The storage-engine internals that sit on top of block live in Database Internals MOC; the S3 deep-dive is Amazon S3 Object Storage System Design; this note owns the vendor-agnostic comparison of the primitives.

Mental Model — Three Ways to Address Bytes

The cleanest way to think about the three paradigms is: what is the smallest thing you can address and manipulate, and how do you reach it? Block storage addresses fixed-size blocks on a device you talk to like a local disk. File storage addresses files in a directory tree you reach with filesystem calls over a network. Object storage addresses whole objects by key over HTTP, and you almost never modify part of one — you replace it wholesale.

flowchart TD
    APP["Your application"]

    APP -->|"read/write blocks<br/>(like a local disk)"| BLOCK["BLOCK STORAGE<br/>raw volume, 1 VM attached<br/>EBS · Persistent Disk · Managed Disk"]
    APP -->|"open/read/write/close<br/>files over NFS/SMB"| FILE["FILE STORAGE<br/>shared POSIX/SMB tree, many clients<br/>EFS · Filestore · Azure Files"]
    APP -->|"GET/PUT object by key<br/>over HTTPS"| OBJECT["OBJECT STORAGE<br/>flat namespace of blobs + metadata<br/>S3 · Cloud Storage · Blob"]

    BLOCK --> DISK["Format with a filesystem<br/>yourself; DB lives here"]
    FILE --> TREE["Provider runs the filesystem;<br/>shared app state, home dirs"]
    OBJECT --> FLAT["Provider runs everything;<br/>media, backups, data lake"]

What it shows and the insight to take: the three differ by the interface they present. Block is the lowest level — a bare device you must put a filesystem on, exclusively yours. File is one level up — the provider runs the filesystem and lets many machines share it. Object is a different axis entirely — not a filesystem at all, but a key-to-blob map spoken over HTTP, trading the ability to do random in-place writes for effectively unlimited scale and durability. A useful mnemonic: databases sit on block, shared application state sits on file, and media/backups/logs sit on object.

Object Storage — A Flat Namespace of Immutable Blobs

Object storage stores data as objects inside buckets. An object is the data plus a set of metadata name-value pairs; a bucket is a container; and every object is identified by a key that is unique within its bucket (What is Amazon S3?). The namespace is flat — despite keys like photos/2026/puppy.jpg that look hierarchical, there are no real directories; the slashes are just characters in the key, and “folders” are a UI convenience over a prefix. Google Cloud Storage states the same model: data stored as objects in containers called buckets, with objects being immutable (Cloud Storage introduction). Azure calls its service Blob Storage, “Microsoft’s object storage solution,” optimized for massive amounts of unstructured data (Azure Storage introduction).

The defining properties:

  • Access is over HTTP(S) via a REST API. S3 is a REST service; every object is addressable by a URL of the form https://bucket.s3.region.amazonaws.com/key (What is Amazon S3?). There is no mounting, no block device, no filesystem call — you GET, PUT, DELETE, and LIST.
  • Objects are immutable / whole-object. You do not edit byte 4,000 of an object in place; you replace the whole object. This is what makes the flat-namespace, replicate-everywhere design tractable at scale. (S3’s large-object limit is very high — objects up to several terabytes, uploaded in parts.)
  • Extreme, engineered durability. S3 Standard and most classes are “designed to provide 99.999999999% durability” — eleven nines — by redundantly storing objects across a minimum of three Availability Zones (S3 data protection). Practically, the odds of losing an object are vanishingly small; the provider continually detects and repairs lost redundancy and verifies integrity with checksums.
  • Consistency is now strong. A common outdated belief is that object stores are only eventually consistent. S3 today provides strong read-after-write consistency for PUTs and DELETEs of objects in all Regions — a read after a successful write returns the new data, and updates to a single key are atomic (S3 consistency model). Note the boundary: object data is strongly consistent, but some bucket configuration changes remain eventually consistent, and there is no cross-key transaction — you cannot atomically update two objects together.
  • Storage classes / tiers. Object stores layer hot→infrequent→archive tiers (S3 Standard, Standard-IA, Glacier Instant/Flexible/Deep Archive; GCS Standard/Nearline/Coldline/Archive; Blob Hot/Cool/Cold/Archive) with lifecycle policies that age data down automatically. This is where object storage’s cost advantage really lands. (Detail: Storage Classes Tiers and Lifecycle Policies.)

Object storage is for: static website assets, images and video, backups and archives, big-data lakes, logs, and any large or numerous immutable blobs. It is the default home for anything you would never fseek into.

Block Storage — A Raw Volume for One Machine

Block storage provides block-level volumes you attach to a virtual machine and use exactly as you would a local hard drive — to store files or install applications (What is Amazon EBS?). The device presents fixed-size blocks; the operating system puts a filesystem (ext4, XFS, NTFS) on top, and from there it behaves like any local disk. Google describes Persistent Disk and Hyperdisk as durable block storage that are network-attached devices transmitting data over Google’s network (Compute Engine disks); Azure Managed Disks are “block-level storage volumes for Azure VMs,” an abstraction over page blobs (Azure Storage introduction).

The defining properties:

  • Low latency, high, consistent performance. Block volumes offer the consistent low-latency performance needed to run demanding workloads (What is Amazon EBS?). This is why databases and boot disks live here — they need fast random reads and writes and in-place mutation, which object storage cannot give.
  • Single-attachment by default. A volume is normally attached to one instance at a time. AWS EBS is generally single-attach (Multi-Attach exists for specific io2 cluster scenarios); GCP disks are typically single-attach with multi-writer available for failover clustering (Compute Engine disks). You cannot casually mount one block volume on twenty servers and expect a shared filesystem — that is what file storage is for.
  • Zone-scoped. A block volume lives in a specific Availability Zone and must be attached to an instance in the same zone; EBS replicates a volume within its AZ for durability (AWS storage services). Some products (GCP regional persistent disks) synchronously replicate across two zones, but the volume is still not a globally addressable object.
  • Volume types trade cost for performance. EBS splits into SSD-backed types for transactional/IOPS workloads (gp3, io2 Block Express) and HDD-backed types for throughput (st1, sc1); io2 Block Express is designed for 99.999% durability while other types sit at 99.8–99.9% (What is Amazon EBS?). You can provision IOPS explicitly for the most demanding databases.
  • Snapshots. Point-in-time backups of a volume, stored durably (on AWS, backed by S3), from which new volumes can be restored across AZs or Regions (What is Amazon EBS?).

Block storage is for: the boot disk of a VM, and the underlying disk of a database (relational or NoSQL), a message broker, or any application that needs a real filesystem with fast random in-place I/O owned by a single node. Details of choosing volume types live in Cloud Block Storage Volumes.

File Storage — A Shared Filesystem Many Clients Mount

File storage gives you a managed shared filesystem — a network file share that many machines mount and access simultaneously through a standard filesystem interface. Amazon EFS provides “a simple, scalable, elastic file system,” designed for massively parallel shared access to thousands of EC2 instances, growing and shrinking automatically, and — critically — it is regional, storing data across multiple Availability Zones for high availability (AWS storage services). Azure Files offers “fully managed cloud file shares” reachable over the industry-standard SMB and NFS protocols, so multiple VMs share the same files with read and write access (Azure Storage introduction). Google Filestore provides fully managed file servers supporting “multiple concurrent application instances accessing the same file system simultaneously,” with POSIX compliance, hard links, and file locking, over NFSv3 (and NFSv4.1 on newer tiers) (Filestore overview).

The defining properties:

  • Multi-attach / shared access. Unlike block, file storage is built to be mounted by many clients at once — that is its entire reason to exist. This makes it the right home for shared application state, content that a fleet of web servers all read, home directories, and lift-and-shift apps that expect a POSIX filesystem.
  • Standard filesystem semantics over the network. You get directories, POSIX permissions, file locking, and hard links — the operations legacy applications assume. On Linux you mount NFS; on Windows you mount SMB.
  • Elastic and managed. The provider runs the filesystem; EFS grows to petabytes automatically without provisioning (AWS storage services). You do not manage file servers.
  • Higher latency and cost than block for single-node work. The convenience of shared network access comes at the price of higher latency than a locally-attached block volume and typically a higher per-GB cost. If only one machine needs the disk, file storage is the wrong (more expensive, slower) choice — use block.

File storage is for: shared configuration and tooling across a fleet, content-management and web-serving where many nodes read the same files, container persistent volumes shared across pods, and lift-and-shift of applications hard-wired to a filesystem. More in Cloud File Storage.

The Three Compared

DimensionObjectBlockFile
UnitObject (blob + metadata), by keyFixed-size block on a raw deviceFile in a directory tree
AccessHTTP/REST API (GET/PUT)Attached device; you add a filesystemNFS / SMB mount
ExamplesS3, Cloud Storage, Azure BlobEBS, Persistent Disk/Hyperdisk, Managed DisksEFS, Filestore, Azure Files
SharingUnlimited concurrent HTTP clientsOne VM (single-attach)Many clients mount at once
MutationWhole-object replace (immutable)Random, in-place, byte-levelRandom, in-place, byte-level
LatencyHigher (HTTP round-trip)Lowest (local-disk-like)Low, but network-bound
ScaleEffectively unlimited, flatPer-volume size cap; per-AZElastic to petabytes
ConsistencyStrong read-after-write per key; no cross-key txnFilesystem/DB you run decidesPOSIX filesystem semantics
DurabilityVery high (S3: 11 nines, ≥3 AZ)High, AZ-scoped (io2: 5 nines)High, multi-AZ (regional)
Typical useMedia, backups, data lake, static assetsDatabase disk, boot volumeShared app state, home dirs, CMS
Cost shapeCheapest per-GB + request + egressProvisioned GB + IOPSPer-GB, higher; pay for sharing

The insight: read the “Sharing” and “Mutation” rows first — they decide almost everything. Need one machine to do fast in-place writes? Block. Need many machines to share a filesystem? File. Storing large immutable blobs at scale for cheap? Object.

Choosing — A Decision Procedure

flowchart TD
    START["Where should this data live?"] --> Q1{"Large immutable blobs<br/>reached over HTTP?<br/>(media, backups, logs, lake)"}
    Q1 -->|Yes| OBJ["OBJECT STORAGE<br/>S3 / GCS / Blob<br/>cheapest, infinite scale, durable"]
    Q1 -->|No| Q2{"Does more than one<br/>machine need to read/write<br/>the SAME filesystem at once?"}
    Q2 -->|Yes| FILE["FILE STORAGE<br/>EFS / Filestore / Azure Files<br/>shared POSIX/SMB"]
    Q2 -->|No| Q3{"Need low-latency, in-place,<br/>random I/O for ONE node?<br/>(database, boot disk)"}
    Q3 -->|Yes| BLK["BLOCK STORAGE<br/>EBS / PD / Managed Disk<br/>attach to one VM, add a filesystem"]
    Q3 -->|"Not sure / small"| OBJ2["Default to OBJECT if the data<br/>is blob-like; else BLOCK"]

What it shows and the insight to take: the decision is a three-question sieve. First ask if the data is blob-like and HTTP-reachable — if so, object storage is almost always right and almost always cheapest. If not, ask whether multiple machines must share one filesystem — if yes, only file storage gives that cleanly. Otherwise you have a single-node, low-latency, in-place-mutation need, which is exactly block storage. The common mistakes are (a) reaching for file storage when only one node needs the disk (block is cheaper and faster), and (b) trying to run a database on object storage (it cannot do fast random in-place writes).

Failure Modes and Common Misunderstandings

  • “Object storage folders are real directories.” They are not. The namespace is flat; a LIST with a prefix simulates a directory. Treating S3 like a filesystem — renaming “folders,” expecting cheap moves — leads to surprise (a “rename” is a copy-then-delete of every object under the prefix).
  • “Object storage is eventually consistent.” Outdated. S3 has been strongly read-after-write consistent since December 2020, in all Regions (S3 consistency model). But there is still no cross-object transaction and no in-place partial update — designs that assumed those must use a database on block instead.
  • “I’ll just mount one EBS volume on all my web servers.” Block is single-attach; you cannot share one volume as a read-write filesystem across a fleet without a clustered filesystem and Multi-Attach, and even then it is fragile. Use file storage.
  • Confusing durability with availability. S3 is designed for 99.999999999% durability (your bytes survive) and 99.99% availability (you can reach them at a given moment) — two independent promises (S3 data protection). Eleven nines does not mean the service never has an outage; it means it almost never loses data. See Durability versus Availability in Cloud Storage.
  • Zone-locked block volumes. An EBS volume in us-east-1a cannot attach to an instance in us-east-1b. Architectures that assume a volume can follow an instance across AZs are wrong; you move data via snapshots.
  • Egress and request costs sneak up. Object storage is cheap per-GB but charges per request and heavily for data leaving the provider’s network — a media workload that serves object storage directly to the internet can rack up egress far exceeding the storage cost. See Egress and Data Transfer Costs.

Production Notes

The canonical production pattern layers all three: a web/application tier stores user uploads and generated media in object storage (S3/GCS/Blob), often fronted by a CDN to cut egress and latency (Content Delivery Networks and Edge Caching); the database that indexes and transacts over that content runs on block storage (EBS/PD/Managed Disks) tuned with provisioned IOPS; and any shared state a fleet of application nodes must all see — uploaded plugins, shared config, a legacy app’s working directory — sits on file storage (EFS/Filestore/Azure Files). A frequent cost optimization is to keep only active data on block/file and lifecycle everything cold into object-storage archive tiers, since object storage is by far the cheapest per gigabyte. Another recurring lesson: applications that were designed for a POSIX filesystem and are “lifted and shifted” into the cloud usually land on file storage first (least code change), then get re-architected onto object storage where the access pattern allows, because object storage scales and costs better. When interviewing or designing, always name the three explicitly and justify the choice from the access pattern — it signals you understand that storage is not one thing.

See Also

Graph View

Backlinks