Object vs Block vs File Storage Explained

"Where do we store the data?" hides three very different answers, and the wrong choice shows up later as poor performance, ballooning cost or an architecture you cannot easily change. This article separates block, file and object storage by the one thing that actually distinguishes them — how you access the data — and maps each to the workloads it fits.

It sits under the cloud computing pillar. It is about how data is stored and served at scale — a different question from the internal memory and storage hierarchy inside a single machine.

Block storage

Block storage presents raw volumes with no built-in structure. The volume is split into fixed-size blocks, and the operating system formats it with a filesystem and mounts it exactly as it would a physical hard disk. This is the world of the SAN (storage area network) and protocols like iSCSI, and in the cloud it is Amazon EBS, Google Persistent Disk or Azure Managed Disks. It delivers the lowest latency and the highest IOPS of the three, which is why it is the home of databases, virtual-machine boot volumes and any transactional workload. Its constraint: a block volume is normally attached to a single server at a time, so it is not built for wide sharing.

File storage

File storage is what most people picture when they think of storage: a hierarchy of folders and files on a shared filesystem, reached over the network. It uses the NAS (network-attached storage) model and protocols such as NFS and SMB, and cloud services like Amazon EFS, Google Filestore and Azure Files. Its defining feature is POSIX filesystem semantics — the standard file operations (open, read, write, rename, permissions) that decades of applications expect — and the fact that many clients can mount and share it at once. That makes it the natural fit for shared drives, content repositories, home directories and lift-and-shift applications that assume a filesystem is there.

Object storage

Object storage breaks with both. There is no filesystem and no volume — just a flat pool of objects, each a blob of data with a unique key and rich metadata, held in buckets and accessed over an HTTP REST API rather than mounted. Amazon S3 defined the model, and its API has become the de facto standard that most other object stores implement.^[1] Object storage trades latency and in-place editing for near-limitless scale, high durability and the lowest cost per gigabyte of the three — you write whole objects rather than editing them in place. That makes it the backbone of backups and archives, media libraries, static website assets, data lakes and the training sets behind AI.^[2]

The comparison that matters

The three side by side — access model is the distinction everything else follows from:

Which to use — and mistakes to avoid

The mapping is usually clear once you name the workload — and so are the classic mistakes:

• Database or transactional app? Block. Do not try to run a production database on object storage — it has no filesystem, higher latency and no transactional semantics.
• Many clients sharing files? File. A block volume attaches to one host; reaching for it to share data across servers is a common and painful error.
• Large, unstructured, or cold data — backups, media, logs, a data lake? Object. Paying block or file prices for cold data that object storage would hold for a fraction of the cost is a silent, recurring waste.
• Do not treat object storage like a filesystem. There is no rename or in-place append; objects are written whole. Applications that assume POSIX behaviour need file storage, not a bucket.

Data residency and PDPA in Singapore

For any storage that holds personal data, where it physically sits is not just a performance question — it is a compliance one. Singapore's Personal Data Protection Act (PDPA) includes a Transfer Limitation Obligation: personal data may only be transferred out of Singapore if the receiving organisation is bound to a standard of protection comparable to the PDPA.^[3] Object storage makes this especially easy to get wrong, because a bucket can be globally distributed or default to a region you did not intend — so knowing and pinning the region your data lives in is a real control, not a detail.

How to choose

A short checklist that avoids the expensive mistakes:

1. Match the access model to the workload — block for databases, file for shared filesystems, object for everything large and unstructured.
2. Pin the region. Decide deliberately where data — and its backups and replicas — physically lives, with PDPA data residency in mind.
3. Model the cost over time. Object is dramatically cheaper for cold and bulk data; block is the most expensive per gigabyte. Tier cold data down to object or archive tiers.
4. Check durability and redundancy. Understand the replication and durability guarantees, and never treat a single copy — of any type — as a backup.
5. Plan the lifecycle. Data cools over time; a lifecycle policy that moves it from block/file to object and then to archive keeps the bill sane.

Designing storage or a data platform?

The right storage mix depends on your workloads, cost profile and residency needs. Compare Singapore cloud and system-integration partners who design and run storage and data platforms.

Browse Cloud & Systems Integrators in Singapore

Frequently asked questions

Sources

1. What is object storage? — Amazon Web Services — AWS official checked 2026-09-01
2. Azure Storage introduction (block, file, object) — Microsoft — Microsoft official checked 2026-09-01
3. Overview of the PDPA and the Transfer Limitation Obligation — Personal Data Protection Commission (PDPC) — PDPC official checked 2026-09-01