Block vs Object vs File Storage: Core Abstraction Differences

Definition
Storage abstraction refers to how a storage system presents data to applications. The three fundamental models are block (raw disk sectors), file (hierarchical paths with POSIX semantics), and object (flat namespace with key value access). Each abstraction trades off flexibility against complexity.
Block Storage: Raw Disk Sectors
Block storage presents raw storage divided into fixed size sectors, typically 512 bytes or 4KB. The application sees a flat sequence of numbered blocks with no structure imposed. Writing block 1000 means exactly that: overwrite bytes at position 1000 times block size. The storage system provides no organization, no naming, no metadata beyond block addresses.
This raw access enables databases and filesystems to implement their own structures. A database writes its B tree pages directly to specific block offsets. There is no intermediary interpreting or transforming the data. Latency is minimal because there is nothing between the application and the disk sectors.
File Storage: Hierarchical Paths with Semantics
File storage adds structure on top of blocks. Data lives at paths like /home/user/document.txt. The storage system maintains a tree of directories, tracks file sizes, permissions, modification times. POSIX semantics mean specific behaviors: reads see the latest write, partial updates are possible, file locks coordinate concurrent access.
This structure costs performance. Every file operation requires metadata lookups. Opening /a/b/c/file means reading directory entries for a, then b, then c, then the file inode. The benefit is familiarity: applications use standard read, write, seek operations unchanged since the 1970s.
Object Storage: Flat Namespace with Immutable Semantics
Object storage eliminates hierarchy. Every object has a unique key in a flat namespace. You PUT an object with key images/photo.jpg and GET it back by that key. The slash is just a character, not a directory. There are no partial updates: you replace the entire object or nothing.
This simplicity enables massive scale. Without metadata dependencies between objects, the system can distribute them across thousands of servers. Writing object A does not require coordinating with object B. The trade off is flexibility: no appends, no in place edits, no file locking. Each object is an atomic, immutable blob.
The Fundamental Trade off
Block gives maximum control but requires building everything yourself. File provides familiar semantics but limits scalability. Object sacrifices random access for horizontal scale. A video streaming platform stores media in object storage (immutable, read heavy) but keeps user session data in block backed databases (random access, updates). Choosing wrong means either building unnecessary complexity or hitting scalability walls.
🎯 When To Use: Block for databases needing direct sector access. File for applications requiring POSIX semantics and shared access. Object for storing immutable blobs at scale with no update requirements.

💡 Key Takeaways

✓Block storage provides raw sectors (512B or 4KB) with no structure, enabling databases to implement custom layouts with minimal latency

✓File storage adds hierarchical paths and POSIX semantics (locking, partial updates) at the cost of metadata overhead per operation

✓Object storage uses flat key value access with immutable objects, enabling distribution across thousands of servers without coordination

✓No partial updates in object storage means replacing entire objects, while block and file support in place modifications

✓Choose block for databases, file for shared access with familiar APIs, object for immutable content at massive scale

📌 Interview Tips

1When asked about storage trade-offs, explain that block gives raw control, file gives familiar semantics, and object gives scale. Then give a concrete example: media files in object storage, metadata database on block storage.

2If the interviewer asks why not just use file storage for everything, explain the metadata coordination bottleneck. Accessing a deep path requires multiple directory lookups, and distributed locking across servers is expensive.

3A common follow-up is how to handle updates in object storage. Explain versioning: upload a new object with the same key, keep old versions for rollback. The immutability constraint becomes an audit advantage.

← Back to Block vs Object vs File Storage Overview