Block, Object and File Storage Types

Every byte an app saves ends up in one of three shapes: a file in a folder, a numbered block on a disk, or an object in a bucket. The shape you pick decides how fast you can read the data, how far it can grow and what it costs to keep.

Three ways to organise the same data

File, block and object storage can all hold the same photo or the same database. What differs is how the data is addressed: how you tell the storage system which piece you want.

• File storage addresses data by a path, such as /recipes/tuna/pie.txt.
• Block storage addresses data by a block number on a volume.
• Object storage addresses data by a unique key in a flat bucket.

Everything else, from speed to price to what each is good at, follows from that choice.

File storage: folders and paths

File storage is the model you already know from your laptop. Data lives in files, files live in folders, and folders sit inside other folders to form a tree. To read something, you give its path, and the system walks the tree to find it.

On a network, the same idea is shared between machines. A file server (often called NAS, network-attached storage) exposes a folder tree over a protocol such as NFS or SMB, and many servers can mount it at once. Managed cloud versions exist too, such as Amazon EFS or Azure Files.

Why people like it

• It is easy to understand. People and programs both know how to work with paths.
• It supports the operations apps expect: open, read part of a file, append, rename, lock.
• Several machines can share one folder tree, which suits shared documents, home directories and tools that expect a normal disk.

Where it struggles

The tree is the strength and the limit. Every lookup walks the folders, and every file carries metadata the system must track: its name, size, permissions and timestamps. As the tree grows to millions or billions of files, keeping that metadata consistent across a shared system gets slow and expensive. Deep folder trees also make it hard to spread data across many machines, because a single folder is one logical place.

That is why file storage is described as organised but limited: comfortable at the size of a team's shared drive, awkward at the size of a photo platform.

Block storage: numbered chunks

Block storage throws away the folders. A volume is split into fixed-size chunks called blocks, each a few kilobytes, and each block has an address: its number. The storage system only understands two requests: 'read block 812' and 'write these bytes to block 812'. It has no idea what a file is.

A block volume behaves like a raw hard drive. In the cloud it is something like an Amazon EBS volume or an Azure managed disk, usually attached to one server at a time.

Why it's fast

Because the storage only deals in numbered blocks, there is almost nothing between the request and the disk. A write can change just the few bytes that changed, in place, without rewriting anything else. Reads and writes are small, direct and low-latency.

That is exactly what databases and virtual machines need. A database updates small pieces of its data files thousands of times a second, and a virtual machine's operating system expects a real disk to boot from.

The software on top

Raw blocks are meaningless to a person. To use a block volume, something has to impose structure on it. That is usually a file system, such as ext4 or NTFS, which keeps a map of which blocks belong to which file. A database engine can play the same role, managing its own blocks directly.

On Linux, attaching a new block volume and making it usable looks like this:

# The volume shows up as a raw device
lsblk
 
# Put a file system on the raw blocks
sudo mkfs.ext4 /dev/xvdf
 
# Mount it, and now it has folders and files
sudo mkdir /data
sudo mount /dev/xvdf /data

Until mkfs runs, the volume is just numbered blocks. That extra layer is what makes block storage fast but more complex: you are responsible for the file system, its size, its backups and which server it is attached to.

Object storage: a flat pile of IDs

Object storage is the newest of the three, and the model behind Amazon S3. There are no folders to walk and no blocks to manage. Everything is an object in a flat container, usually called a bucket.

Data, ID and metadata

Each object has three parts:

• The data: the bytes themselves, such as a photo or a backup file.
• A unique ID: the object's key, such as users/42/avatar.jpg.
• Metadata: extra information stored with it, such as its content type, who owns it or a custom tag.

The slashes in a key look like folders, but they are just characters in a name. Tools show them as folders for convenience; the storage sees one flat list of keys. You never navigate to an object. You ask for it by key, usually over an HTTP API.

Why it scales and why updates are slow

A flat list of keys is easy to spread across huge numbers of machines, because no object depends on a parent folder. That is what lets object storage grow to effectively any size, and why it is cheap per gigabyte: providers can store the data on plain, dense hardware and handle copies for you.

The trade-off is that objects are written whole. You generally can't change a few bytes in the middle of an object the way you can on a block volume. To update it, you upload a new version of the entire object. That is fine for a photo that is written once and read many times, and terrible for a database that changes small pieces constantly. Requests also go over the network through an API, so each one has more latency than a local disk read.

A worked example

Here is how an app stores and fetches a profile photo in S3 with Python and boto3:

import boto3
 
s3 = boto3.client("s3")
 
# Store: a key, the bytes and some metadata
with open("avatar.jpg", "rb") as f:
    s3.put_object(
        Bucket="kitty-photos",
        Key="users/42/avatar.jpg",
        Body=f,
        ContentType="image/jpeg",
        Metadata={"owner": "42"},
    )
 
# Fetch: ask by key, no folders to walk
obj = s3.get_object(
    Bucket="kitty-photos",
    Key="users/42/avatar.jpg",
)
photo = obj["Body"].read()

Notice what is missing. There is no mount, no file system and no server the bucket is attached to. Any machine with permission can read the object by its key. To change the photo, the app calls put_object again with the same key and the whole object is replaced.

Side by side

In one line each: file storage is organised but limited, block storage is fast but complex, and object storage is scalable but simple.

Choosing for a real app

Most real systems use all three, each for the data it suits. Picture a photo-sharing app:

• The database of users, likes and comments runs on a block volume. It needs fast, small, in-place writes, and the database engine manages the blocks.
• The uploaded photos and videos go into object storage. They are written once, read many times, can grow without limit, and the app only ever fetches them by key.
• A shared folder that several image-processing servers read and write at once sits on file storage, because those tools expect ordinary paths and need to see the same files.
• Nightly database backups are exported and copied into object storage too, where cheap, durable space matters more than speed.

The question to ask for each kind of data is how it is written and read. Small, constant updates point to block. Large, write-once files point to object. Many machines sharing ordinary files point to file.

Common mistakes

• Running a database on object storage. Every small change would mean rewriting a whole object over the network. Databases belong on block storage.
• Treating S3 keys as real folders. Renaming a 'folder' in a standard S3 bucket means copying and deleting every object under that prefix, one by one. Design keys up front so you rarely need to move them.
• Using block storage as a shared drive. A block volume is usually attached to one server. If several servers need the same files, use file storage or object storage instead.
• Keeping large media on the app server's disk. It fills the volume, ties the files to one machine and complicates scaling. Put media in object storage and store only the key in the database.

Key takeaways

• File, block and object storage differ in how data is addressed: by path, by block number or by key.
• File storage is easy and shareable, but its folder tree gets hard to scale.
• Block storage is fast and supports in-place writes, so it suits databases and virtual machines, but it needs a file system or database on top.
• Object storage keeps data, a unique ID and metadata in a flat bucket, scales cheaply, and replaces whole objects on update. It is how S3 works.
• Real systems mix all three, choosing by how each kind of data is written and read.