System Design
File Storage vs Object Storage vs Block Storage
Three ways to store data, three completely different models - and choosing wrong leads to systems that don't scale or cost a fortune. Here's what each is, how data is actually accessed in each, and when to reach for which.
"Where do we store the data?" sounds like one question, but it's really three, because there are three fundamentally different ways to store data - file storage, block storage, and object storage - and they're not interchangeable. They differ in how data is organized, how it's accessed, how they scale, and what they cost. Choosing the wrong one leads to systems that don't scale, cost far too much, or simply can't do what's needed. In system design, knowing which storage model fits a problem - "store the user's uploaded videos" versus "store the database's data" - is a real signal of understanding.
This guide lays out all three: what each is, how data is actually accessed in each, and when to reach for which.
graph TD
BLOCK[Block Storage] --> B1[Raw blocks, like a virtual disk<br/>Low-level, fast, attached to one machine]
FILE[File Storage] --> F1[Files in folders, hierarchical<br/>Accessed by path, shared]
OBJECT[Object Storage] --> O1[Objects + metadata, flat namespace<br/>Accessed by key via API, massive scale]
This diagram contrasts the three storage models. Block storage presents raw blocks like a virtual disk - low-level, fast, and attached to one machine. File storage organizes data as files in a hierarchy of folders, accessed by file path and often shared. Object storage stores objects with metadata in a flat namespace, accessed by a key through an API, and scales massively. Each is a fundamentally different way of organizing and accessing data.
Block storage: raw blocks, like a hard drive
What it is. Block storage is the lowest-level model. It presents storage as a series of fixed-size blocks, like a raw hard drive, with no inherent structure of files or folders. Something has to be layered on top - typically a file system or a database - to organize those blocks into something usable. Think of it as a blank virtual disk you attach to a machine.
How data is accessed. A block volume is attached to a single server (like plugging in a hard drive), and that server reads and writes blocks directly, usually by putting a file system on top. Access is low-level and fast.
When to use it. When you need high-performance, low-latency storage for a single machine - most importantly, as the storage underneath databases and for the disks of virtual machines. Databases want direct, fast, block-level access to manage their own data layout, and block storage gives them exactly that. If something needs to behave like a fast local disk, it's block storage. Cloud examples are services that provide attachable disk volumes for VMs.
Trade-offs. Block storage is fast but typically attached to one machine at a time, and it doesn't scale to massive sizes the way object storage does. It's the right tool for performance-sensitive, single-machine storage (databases, VM disks), not for storing billions of files shared across the internet.
File storage: files and folders
What it is. File storage is the model everyone knows from their own computer: data organized as files arranged in a hierarchy of folders/directories. Each file has a path (like /users/alice/report.pdf), and you navigate the hierarchy to find things. A file system manages this structure.
How data is accessed. By file path, through standard file operations (open, read, write). Crucially, file storage can be shared - a network file system lets multiple machines mount the same file storage and access the same files (network-attached storage, NFS). So several servers can read and write a common set of files.
When to use it. When you need shared access to files in a familiar hierarchical structure - shared drives, content shared across servers, applications that expect a traditional file system, home directories. When multiple machines need to work with the same files using normal file operations, file storage fits.
Trade-offs. File storage is intuitive and supports sharing, but the hierarchical structure becomes a bottleneck at extreme scale - managing billions of files in a folder hierarchy gets unwieldy and slow. It scales further than block storage (and can be shared) but doesn't reach the effectively-unlimited scale of object storage.
Object storage: objects in a flat namespace
What it is. Object storage is the model built for the cloud era and massive scale. Data is stored as objects - each object is a blob of data plus metadata plus a unique identifier (key) - in a flat namespace (no folder hierarchy; just keys mapping to objects). You store and retrieve whole objects by their key, typically through an API over the network.
How data is accessed. By key, through an API (usually HTTP-based) - GET the object with this key, PUT this object at this key. There's no mounting a drive or navigating folders; you make API calls to store and retrieve objects. Objects are generally written and read whole, not modified in place piece by piece.
When to use it. When you need to store large amounts of unstructured data, cheaply, durably, and at effectively unlimited scale - images, videos, file uploads, backups, logs, data lakes, static website assets. This is the answer to "where do we store user-uploaded photos and videos" in system design. Object storage is built to hold billions of objects, accessed over the web, with high durability and low cost. Cloud examples are the major object storage services.
Trade-offs. Object storage scales massively and is cheap and durable, but it's not for everything: you access whole objects by key (no rich querying, no in-place editing of part of a file), and latency is higher than block storage (it's over the network, built for throughput and scale rather than low-latency single-machine access). It's perfect for big, unstructured, write-once-read-many data - and wrong for a database's working storage.
The three compared
| Block storage | File storage | Object storage | |
|---|---|---|---|
| Model | Raw blocks (virtual disk) | Files in folders (hierarchy) | Objects + metadata (flat namespace) |
| Accessed by | Block-level, via a file system | File path | Key, via API |
| Sharing | Usually one machine | Shared across machines | Accessed over the web by many |
| Scale | Limited | Moderate | Effectively unlimited |
| Latency | Lowest | Moderate | Higher (network) |
| Best for | Databases, VM disks | Shared files, NAS | Images, video, backups, data lakes |
| Mental model | A hard drive | A shared network drive | A giant key-value store for files |
How to choose: a simple decision guide
With three models, the choice is usually clear once you ask what you're storing and how it's accessed:
- Is it a database's working storage, or a VM's disk? → Block storage. Databases and virtual machines need fast, low-level disk access, and block storage is what behaves like a local disk.
- Do multiple machines need to share files through a normal file system? → File storage. When several servers mount and work with the same files using standard file operations, file storage fits.
- Is it large unstructured data - images, video, uploads, backups - accessed over the web at scale? → Object storage. When you're storing lots of big files cheaply and durably, accessed by key over an API, object storage is the answer.
The questions map almost one-to-one to the three models, because each was built for a different need. The mistakes happen when you ignore the fit - putting large media files in a database (which belongs in object storage), or trying to use object storage as a database's working disk (which needs block storage's low latency). Match the model to what you're actually storing and how it's accessed, and the choice is usually obvious.
A worked example: handling a video upload
Trace what happens when a user uploads a video, to see the models cooperate. The video file - large, unstructured - is stored in object storage, which returns a key identifying it. The application then records a row in its database (sitting on block storage): the video's metadata (title, uploader, timestamp, and crucially the object storage key). The actual bytes live in object storage; the database holds only the small metadata record and the pointer.
When someone watches the video, the application looks up the metadata in the database (fast, on block storage), gets the object key, and serves the video from object storage (often through a CDN for speed and scale). At no point is the large video file stored in the database - that would bloat the database, blow past its storage, and serve poorly. The division of labor is clean: object storage holds the big bytes at scale and low cost, the database holds the queryable metadata and the pointer, and block storage gives the database the fast disk it needs.
This pattern - large files in object storage, metadata and pointers in a database - is so common and important that recognizing it is a baseline system-design skill. Any time a design involves media or large files, this is the shape of the answer.
Durability, cost, and the CDN connection
A few more practical properties, especially about object storage since it's where large data lives:
- Durability. Object storage services are built for extremely high durability, typically replicating each object across multiple machines and locations automatically, so objects survive hardware failures. This is part of why object storage is trusted for backups and irreplaceable data.
- Cost. Object storage is generally the cheapest per gigabyte of the three, which is exactly why it holds the bulk of large unstructured data. Block storage (fast disks) costs more per gigabyte, so you don't waste it on data that doesn't need its speed.
- The CDN pairing. Object storage is commonly paired with a content delivery network: the objects live in object storage, and a CDN caches them at edge locations close to users for fast delivery. This is how images and videos are served quickly worldwide - object storage as the origin, CDN as the fast distribution layer.
These properties reinforce why the three models exist: each occupies a different point on the speed-scale-cost spectrum, and you use each where its properties fit.
Common mistakes to avoid
A few storage mistakes show up repeatedly, and knowing them is part of choosing well:
- Storing large files in a database. Putting images, videos, or big documents directly into database rows bloats the database, hurts performance, and doesn't scale. Large files belong in object storage, with the database holding a pointer.
- Using object storage as a database's working disk. Object storage's higher latency and whole-object access make it wrong for the fast, low-level, in-place access a database needs - that's block storage's job.
- Forgetting that object storage objects are typically replaced whole. You generally replace whole objects rather than editing part of a stored file in place, so object storage suits write-once-read-many data, not data needing constant small in-place edits.
- Not using a CDN for media served to users. Serving large media directly from object storage to a global audience is slower and costlier than fronting it with a CDN.
Each mistake comes from using a storage model for a job it isn't built for - which is exactly why understanding the three models and their fit matters.
Managed cloud storage
In practice, most teams use managed cloud storage services rather than running their own. Cloud providers offer each model as a service - block volumes you attach to virtual machines, managed file storage you can mount across machines, and object storage accessed by API - handling the durability, scaling, and operations for you. This is why object storage in particular became ubiquitous: a managed object store gives you effectively-unlimited, highly-durable, cheap storage accessed by a simple API, with none of the operational burden of running it yourself. When designing systems today, you're usually choosing which managed storage service fits each need - and the three models are exactly the categories those services fall into.
How they fit together in a real system
These aren't competing choices for the same job - a real system uses different ones for different needs. Picture a video platform:
- Block storage underlies the databases that hold user accounts, video metadata, and comments - the databases need fast, low-level disk access.
- Object storage holds the actual video files and thumbnails - huge, unstructured, accessed over the web, needing massive scale and low cost. The database stores metadata and a pointer (the object key) to each video in object storage.
- File storage might be used where servers need to share a common set of files in a traditional file-system way.
The pattern with object storage is especially worth knowing: you don't store large files in your database (that bloats it and doesn't scale) - you store the file in object storage and keep a reference to it in the database. The database holds the metadata and the object key; the object store holds the bytes. This database-plus-object-storage pairing is one of the most common and important patterns in system design.
Interview: Storage type comes up directly in system design, especially around media. When a design involves user uploads - photos, videos, files - the expected answer is object storage for the files themselves, with the database storing metadata and pointers to them, not the files. Stating that clearly ("store the videos in object storage, keep the metadata and object keys in the database") signals you understand how large-scale systems handle media. And knowing that databases sit on block storage, while shared files use file storage, rounds out a complete picture of where different data lives.
The bottom line
There are three fundamentally different storage models. Block storage presents raw blocks like a virtual disk - fast, low-level, attached to one machine - and underlies databases and VM disks. File storage organizes data as files in a folder hierarchy, accessed by path and shareable across machines - good for shared files and traditional file-system needs. Object storage stores objects (data plus metadata) by key in a flat namespace, accessed via API - built for massive, cheap, durable storage of unstructured data like images, videos, and backups.
They're not interchangeable; real systems use each for what it's best at, most commonly pairing a database (on block storage) with object storage for large files, keeping the bytes in the object store and a pointer in the database. Know the three models and you'll always know where a given piece of data belongs. We cover storage and the patterns around it across System Design Fundamentals.
Go deeper
- Object storage (Wikipedia) - the object model and its scale properties.
- Block-level storage (Wikipedia) - the raw-block model underlying databases and VMs.
- AWS - What is Object Storage? - a practical comparison of the storage types.
- File system (Wikipedia) - how hierarchical file storage organizes data.