Block vs File vs Object Storage: Which Fits Which Job

Choosing between block vs file vs object storage goes wrong quietly. The wrong pick rarely fails on day one. It fails as the data grows, as slow listings, backups that run into the next day, lost writes or a bill nobody planned.

Picture a common setup. A mid-sized cooperative bank with about 3.2 lakh (320,000) members is moving from its own data centre to the cloud. Its infrastructure team must decide where each kind of data will live. The setup is made up, but the problem is real.

The team lists what has to move. Each item reads and writes in its own way.

• The core banking database, about 1.4 TB. It changes thousands of times a minute, a few bytes at a time, and must never lose a committed entry.
• Cheque-clearing batch files. Three batch servers read and write the same folders every evening, renaming files as each stage finishes.
• KYC (Know Your Customer) scans, the identity documents members upload. There are about 62 lakh (6.2 million) PDFs and photos, around 21 TB, and almost none ever change.
• Nightly database backups and monthly statements, written once and kept for years.

In the old data centre, everything except the database sat on one big shared drive. Listing the KYC folder took minutes. Backing up the share took 19 hours, so it ran into the next working day.

Then a vendor suggested putting the database files on the cheapest storage on the price list. The team said no. This guide explains why, which storage fits each job, and how to defend each choice in an interview.

You need five words: block, file system, object, latency and throughput. Each gets a plain meaning here, so later sections can use them freely.

Block. A block is a fixed-size chunk of storage with a number. A disk only understands numbered chunks like these, usually 512 bytes or 4 KiB (4,096 bytes) each. It has no idea which blocks belong to which file.

File system. A file system is software that turns numbered blocks into named files inside folders. It keeps tables that say which blocks hold which file. Linux examples are ext4 and XFS.

Object. An object is one whole item, such as a PDF, stored with a key and metadata. The key is its unique name, and metadata is small facts about it, like its content type. An example key is kyc/2026/10/member-88213.pdf.

Latency and throughput. Latency is how long one request takes, from asking to getting the answer. Throughput is how much data moves per second. A database cares about latency on each tiny read, while a backup job cares about throughput.

The difference is the unit you work with and who can share it. Block storage hands one server raw numbered blocks. File storage hands many servers shared files in folders. Object storage hands any permitted app whole items by key over HTTP.

One everyday picture helps: the three ways a village can store rice after the harvest.

Loose grain on a threshing floor is block storage. You can scoop a handful from any spot, fast, but the floor has no labels. Only the farmer who spread it knows what is where, just as only the file system knows which blocks mean what.

Sacks in a labelled storeroom are file storage. Every sack sits on a named row, and several workers can find a sack by row and label. A storekeeper stops two people from grabbing the same sack, like a file lock.

Sealed lots sent to a government grain warehouse are object storage. You hand over a whole sealed lot and get a lot number back. Later you quote the number and get the whole lot. To change it, you send a new lot.

Where the picture breaks: a cloud object store usually keeps copies of every lot in separate buildings and hands one back in a fraction of a second. No village warehouse does either.

Here is how the three kinds sit in the bank's new design. NFS (Network File System) is the common way Linux servers share folders over a network. PUT and GET are the HTTP requests that save and fetch an object. Notice that only the database servers touch the block volume, and that members never reach the object store directly.

The table puts the three side by side. Its figures come from AWS (Amazon Web Services) documentation as of 19 October 2026. Other clouds use different numbers.

AWS sells block storage as EBS (Elastic Block Store), file storage as EFS (Elastic File System) and object storage as S3 (Simple Storage Service). General purpose buckets are S3's standard kind of bucket.

In the latency row, io2 Block Express is the EBS SSD type with the lowest latency, and gp3 is its general purpose SSD type. EFS Regional means a file system stored in several data centres of one region. SMB is the file-sharing protocol used mostly by Windows.

Block storage is a virtual disk that a server sees as its own drive. Use it when one server needs fast, small, random reads and writes, like a database or an operating system disk.

A cloud block volume behaves like a local disk. The Amazon EBS documentation says that after you attach a volume, you use it like a local hard drive. EBS also copies the volume's data across several servers inside one Availability Zone, a group of one or more data centres within a region.

The volume itself has no files. The team formats it with XFS, which writes its own tables onto the blocks. PostgreSQL then keeps its data files on top, storing each table in pages that are usually 8 kB.

To change one account balance, PostgreSQL edits one page in memory and adds a record to its write-ahead log (WAL). The WAL is a file where every change is recorded first. With default settings, only that log record must reach the disk at commit. The changed page is written back later.

The log record is usually small. With the default full_page_writes setting, the first change to a page after a checkpoint, a regular flush of changed pages, copies the whole 8 kB page into the log. Either way, both writes are small and land inside big files. That is exactly the access pattern block storage is built for, and why the vendor's idea worried the team.

Why is block storage usually tied to one server?

An ordinary file system assumes it is the only writer. AWS warns that standard file systems such as XFS and EXT4 are not designed for simultaneous access by multiple servers.

Some volumes can still be shared. EBS Multi-Attach lets one io1 or io2 volume attach to up to 16 Nitro-based instances, AWS virtual servers on its current hardware platform, in the same Availability Zone. AWS says you then need a clustered file system, one built for several writers, and your applications must order their own writes.

Use block storage for these jobs:

• Relational databases such as PostgreSQL or MySQL, where small writes must land fast and in order.
• Boot disks, which hold each server's operating system.
• Any software whose install guide asks for a local disk.

Back up block volumes with snapshots, point-in-time copies of the whole volume. EBS snapshots persist independently of the volume, and you can use them to move data to another Availability Zone or Region.

File storage is a shared tree of folders and files that many servers mount over the network at once. Use it when several servers must read and write the same files by path, with renames and locks.

The common protocols are NFS, used mostly by Linux servers, and SMB, used mostly by Windows. NFS version 4.1 is specified in RFC 8881, published in August 2020, and includes file locking.

The bank's clearing job fits well. Server one writes batch_1015.csv into an incoming folder. When it is done, it renames the file into a ready folder. Server two only picks up files from ready, so it never sees a half-written batch, provided server one closes the file first. The engineer section shows why.

That rename is the key move. Inside one file system, a rename changes folder entries, so the file's data does not move. On Linux, rename replaces any existing target atomically, so no other process ever finds the name missing.

Managed file services run the file servers for you. The Amazon EFS documentation lists NFS versions 4.0 and 4.1, strong data consistency and file locking. Regional EFS file systems store data across several Availability Zones in one region.

Use file storage for these jobs:

• Shared folders that many servers or people edit, such as report drops and home directories.
• Older applications that only know how to open a path and that you cannot rewrite yet.
• Batch pipelines that hand off work by moving files between folders.
• Web servers that share uploaded media in a content management system.

Object storage keeps whole items, each under a unique key, inside a container called a bucket, and you reach it with HTTP calls. Use it for large amounts of data that are written once and read many times.

You do not mount a plain bucket like a disk, though S3 Files, covered later, changes that. Your code sends a PUT to save an object and a GET to fetch it. The S3 documentation says an object is data plus metadata, and every object has exactly one key in its bucket.

S3 general purpose buckets have a flat structure, not a folder tree. The console shows folders only by grouping keys that share a prefix, like kyc/2026/10/. AWS says those folders cannot be renamed.

This is the grain warehouse again. Each lot has a number, the warehouse does not care what is inside, and it returns whole lots at a scale no village storeroom could match.

Here are the three ways of writing data side by side, in plain Python you can run. The object part uses ToyObjectStore, a tiny stand-in that, like a real object store, only accepts whole values under keys.

import os, shutil, tempfile

BLOCK = 4096                              # bytes per block in this demo
work = tempfile.mkdtemp()

# Block: a 1 MiB file stands in for a raw disk, reached by block number
disk_path = os.path.join(work, "disk.img")
with open(disk_path, "wb") as disk:
    disk.truncate(256 * BLOCK)            # 256 empty blocks
with open(disk_path, "r+b") as disk:
    disk.seek(7 * BLOCK)                  # jump straight to block 7
    disk.write(b"x" * BLOCK)              # overwrite exactly one block
print("disk size:", os.path.getsize(disk_path), "bytes")

# File: a path inside folders; you can append, then rename
for folder in ("incoming", "ready"):
    os.makedirs(os.path.join(work, folder))
src = os.path.join(work, "incoming", "batch_1015.csv")
with open(src, "a") as f:
    f.write("CHQ-118204,4500.00\n")         # add one line at the end
os.rename(src, os.path.join(work, "ready", "batch_1015.csv"))
print("ready folder:", os.listdir(os.path.join(work, "ready")))

# Object: a toy store that only knows whole values under keys
class ToyObjectStore:
    def __init__(self):
        self._objects = {}
    def put(self, key, data):
        self._objects[key] = bytes(data)  # replaces the whole value
    def get(self, key):
        return self._objects[key]

store = ToyObjectStore()
key = "kyc/2026/10/member-88213.pdf"
store.put(key, b"page1-blurred|page2")
fixed = store.get(key).replace(b"blurred", b"clear")  # edit a local copy
store.put(key, fixed)                     # upload the whole value again
print(key, "->", store.get(key))
shutil.rmtree(work)                       # tidy up the demo folder

Run it with python3 (we used 3.13) and it prints three lines. First comes disk size: 1048576 bytes, then ready folder: ['batch_1015.csv'], then the key followed by b'page1-clear|page2'.

What just happened? The seek to block 7 shows block storage: you jump to a number, not a name. The append and rename show file storage. The object part fixed one word by editing a local copy and uploading the whole value again.

Use object storage for these jobs:

• Documents, photos and videos uploaded by users, such as KYC scans.
• Backups and archives, including database dumps and exported snapshots.
• Logs and analytics data, written in large chunks and read in bulk.
• Static website files and downloads served through a CDN, a network of caches close to users.

Choose by asking how the data is written, how much changes at once, and how many servers share it. Small random edits from one server mean block. Shared paths mean file. Whole items written once mean object.

Follow the questions from the top. Each answer sends you down one arrow, and the last box sends unclear workloads back for more detail.

The same questions fit in a small function. The order of the checks matters: small random writes come first, because a database on the wrong storage is the costliest mistake.

from dataclasses import dataclass

@dataclass
class Job:
    name: str
    small_random_writes: bool   # updates a few KB in the middle, often
    shared_by_servers: bool     # several servers open the same paths
    needs_paths_or_locks: bool  # renames, folders, file locks
    written_once: bool          # saved whole, read back whole

def pick_storage(job: Job) -> str:
    if job.small_random_writes and not job.shared_by_servers:
        return "block"          # databases, boot disks
    if job.shared_by_servers and job.needs_paths_or_locks:
        return "file"           # shared folders, batch hand-offs
    if job.written_once:
        return "object"         # scans, statements, backups, logs
    return "ask again"          # unclear: get more detail first

jobs = [
    Job("core banking database", True, False, False, False),
    Job("cheque-clearing batches", False, True, True, False),
    Job("KYC scans", False, False, False, True),
    Job("backups and statements", False, False, False, True),
    Job("shared scratch space", False, True, False, False),
]
for job in jobs:
    print(f"{job.name}: {pick_storage(job)}")

Running it prints five lines, one per job. The database gets block, the clearing batches get file, and the scans and backups get object. The shared scratch space gets ask again. That last job is shared but needs no paths, so the function refuses to guess.

Here is the bank's list, placed:

1. 1

   Core banking database

   Small random writes on one primary server. Block storage, with a replica server that holds its own block volume.

2. 2

   Cheque-clearing batches

   Three servers share folders and rely on renames. A managed NFS file system.

3. 3

   KYC scans

   Saved whole, read whole, almost never changed. Object storage, with a new key for every upload.

4. 4

   Backups and statements

   Written once and kept for years. Object storage, moved after 90 days to a colder, cheaper storage class (a price and speed tier) by a lifecycle rule, a bucket setting that acts on object age.

Each kind of storage answers differently, and the answer shapes your design. Block storage leaves it to a clustered file system. File storage offers locks and atomic renames. Object storage, by default, keeps the last write and drops the other.

Object storage: the last writer wins unless you ask

Pause and predict. Two upload servers PUT different scans to the same key at the same moment. What does the bucket hold afterwards?

It holds exactly one of them. S3 says it does not lock objects for concurrent writers. If two PUT requests to one key arrive together, the request with the latest timestamp wins, and nothing is merged.

Reads are simpler. S3 gives strong read-after-write consistency, so a read that starts after a successful PUT returns the new data. A single key also updates atomically, so a reader gets the old object or the new one, never a mix.

S3 also supports conditional writes. A PUT with If-None-Match set to * succeeds only if the key does not exist yet. Otherwise S3 answers 412 Precondition Failed and keeps the old object. If a delete races the PUT, S3 can answer 409 Conflict, and the PUT can be retried.

A PUT with If-Match carries the ETag you last read, an identifier S3 gives each object version. It succeeds only if nobody changed the object since. If several conditional writes race, the first to finish wins and the rest get 412.

File storage: close, then rename

NFS has locks, but most hand-offs between servers use a simpler pattern: write, close, then rename. The order matters because NFS clients cache data.

The Linux nfs manual calls the rule close-to-open consistency, using NFS version 3 as its example. Amazon EFS, where the bank's clearing folders live, says it provides the close-to-open consistency that applications expect from NFS. When a program closes a file, the client writes back any pending changes. When the next program opens it, the client checks with the server first.

So server one must close batch_1015.csv before renaming it into ready. Server two opens it only after it appears in ready, and reads the full file. Rename before closing, and the last writes may still sit in server one's cache.

Server two may not see the new name straight away. Its NFS client caches folder information for up to 60 seconds by default on Linux, so poll ready/ instead of expecting the file instantly.

One more warning from the Linux rename manual: on NFS, a failed rename call does not prove the file was not renamed. Check where the file is before you retry.

Block storage: only with help

A block volume has no sharing rules of its own. AWS says Multi-Attach io1 and io2 volumes support I/O fencing, which controls write access between servers, but your applications must still order their writes.

Because an S3 general purpose bucket has no folder to rename, only keys that share a prefix. Renaming kyc/2026/ means copying every object to a new key and deleting the old one.

For the bank's 62 lakh scans, that is 62 lakh copy requests plus 62 lakh deletes, and S3 bills the copy requests. A file system does the same rename by changing one folder entry.

Directory buckets are the exception. They organise objects into hierarchical directories, and RenameObject atomically renames one object, but only in the S3 Express One Zone storage class. As of 19 October 2026, each RenameObject call renames one object, and it rejects keys ending in a slash. The same class also lets you append data to the end of an object, up to 10,000 times.

This is why key design matters. The bank names each scan with the member number and upload time, so it never needs to move them, and old scans can be found and deleted by prefix.

You can run PostgreSQL on NFS if you mount it carefully, but you should not run a normal database on object storage. Databases need small in-place writes, and an object in a general purpose bucket can only be replaced whole.

PostgreSQL 18's documentation says the data directory can live on NFS. The only firm requirement is mounting with the hard option, so the client retries requests instead of failing them. It also strongly recommends the sync export option on the NFS server.

Without that sync export option, an fsync (the call that forces data onto disk) on the client may not mean the data reached the server's disk. The documentation compares the corruption risk to running with fsync turned off.

Every write also crosses the network. AWS quotes about 2.7 ms per write on EFS at best, against an average under 0.5 ms for 16 KiB operations on io2 Block Express volumes.

On object storage, each tiny page change would mean uploading a whole object again. That is what the vendor's cheap idea missed.

There is one important exception: systems designed from the start for object storage. Apache Iceberg, an open table format for analytics, never edits a file. Its specification says data and metadata files are immutable once written, and compatible with object stores like S3.

Iceberg commits by atomically swapping a pointer to a new metadata file. If another writer committed first, the writer retries on the new version. The design works because it replaces objects instead of editing them.

Partly. S3 Files, launched on 7 April 2026, lets you mount any S3 general purpose bucket over NFS 4.1 or 4.2. Underneath, the bucket still stores whole objects, and the user guide says your authoritative data always remains in S3.

S3 Files is built on Amazon EFS and keeps recently used data on that fast file layer. When you change a file, it waits for 60 seconds without writes. Then it copies the file back to the bucket as a new object version.

Renames show the old rule underneath. Renaming a file writes a new object and deletes the old one, and renaming a directory repeats that for every object under the prefix. By default, S3 Files refuses to create a file system on a prefix so large that a rename could take up to 4 hours. That is about 12 million objects.

Conflicts go to the bucket. If another app changes an object directly while the file system holds unsynced edits, the bucket's version wins. Your edited file moves to a lost and found directory.

For the bank, nothing changes. The clearing folders need fast renames and locks, so they stay on EFS. The KYC scans stay as plain objects behind the documents service.

Explain it as three ways to reach bytes, then place each part of your design on one of them with a reason. Interviewers want the reason more than the label.

1. 1

   Name the three units

   Blocks for one server, files and paths for shared access, objects and keys for huge scale. Keep this to two sentences.

2. 2

   List the data in your design

   For a bank: the ledger database, shared batch files, uploaded documents and backups. Say how each one is written and read.

3. 3

   Place each piece

   Ledger on block volumes with a replica, batch files on a managed file system, documents and backups in object storage.

4. 4

   Name one risk per choice

   A block volume lives in one Availability Zone, so plan snapshots. NFS hand-offs need close before rename. Plain object PUTs are last-writer-wins unless you use conditional writes.

5. 5

   Talk about cost

   Say how each is billed: provisioned size and speed for block, stored bytes plus requests for object. Then estimate the size of the biggest store.

6. 6

   Draw the flow

   Show the app uploading through a service that checks access and picks the key, never straight from the phone with open permissions.