Object storage or block storage: which one you actually need

Cloud platforms sell several storage products that all, at a sufficient level of abstraction, store your data. They are not interchangeable, and the differences show up as either cost or scaling pain depending on which way you get it wrong.

The three shapes

Block storage presents a raw device that you format with a filesystem and mount. From the operating system’s perspective it is a disk. It attaches to one instance at a time, offers low latency, and supports arbitrary reads and writes anywhere in a file. This is what your instance boots from and what a database writes to.

Object storage presents a flat namespace of objects addressed by key, accessed over HTTP. There is no filesystem and no partial write: you put a whole object or you get a whole object. It scales essentially without limit, is accessed by many clients simultaneously, and costs considerably less per gigabyte.

File storage presents a shared filesystem that several instances can mount at once, using a network file protocol. It fills the gap where multiple machines genuinely need to see the same directory tree.

Choosing correctly

Use block storage for anything requiring a filesystem or low-latency random access: operating system disks, database data directories, message broker storage, search indexes, and any application that expects to open a file and seek within it.

Use object storage for anything written once and read many times, and for anything that grows without bound: user uploads, images and video, backups and archives, static site assets, data lake contents, and logs.

Use file storage when several instances must share a filesystem and you cannot restructure to avoid it. It is the most expensive per gigabyte and the answer to a real but narrower problem.

The mistake that hurts most

Storing user uploads on the application server’s block storage is the single most common storage mistake, and it is not obviously wrong at the time.

It works fine on one server. Then it prevents you from running a second server, because the uploads only exist on the first. It makes the machine stateful, so rebuilding it means migrating data. It makes backups larger and slower. And the disk eventually fills, which takes the whole application down rather than just breaking uploads.

Object storage solves all of that, and it is cheaper. If you are building something new, put uploads in object storage from the first day, even when a directory would work. Retrofitting it later is a migration with a cutover.

Cost behaves differently

Block storage bills for provisioned capacity: allocate a hundred gigabytes and pay for a hundred gigabytes whether or not anything is on it. Higher-performance tiers bill more, and some bill separately for provisioned throughput.

Object storage bills for what is stored, plus requests, plus data transfer out. Storage tiers trade retrieval cost against storage cost: colder tiers are cheaper to keep and more expensive, and slower, to read.

Two consequences follow. Over-provisioned block volumes waste money continuously and invisibly, so check for volumes far larger than their usage. And object storage with many small objects can be dominated by request charges rather than storage charges, which makes batching small writes worthwhile.

Lifecycle rules pay for themselves

Object storage supports rules that move objects between tiers or delete them as they age. This is the closest thing to free money in cloud storage, and it is frequently unconfigured.

Typical policies: move objects to a cheaper tier after thirty days, to archive after ninety, and delete after whatever your retention obligation requires. Log data and backups are the obvious candidates, and they are also usually the largest volume.

Set the rules when you create the bucket. Retrofitting them means reasoning about existing data, and nobody enjoys that.

Compatibility is worth choosing for

Many providers offer object storage with an S3-compatible interface. This matters more than it sounds: it means existing libraries, command-line tools, backup software and frameworks work without modification, and it keeps the door open to moving between providers later.

Where you have a choice, prefer the compatible option. Proprietary interfaces are a lock-in decision made for very little benefit.

Practical notes

Snapshots of block storage are the fast operational recovery mechanism, and they are not a substitute for an independent backup.

Object storage buckets must not be public by default. Accidental public exposure of a bucket is one of the most common data breaches, and it is almost always a misconfiguration rather than an attack. Serve public content through a CDN in front of a private bucket, and enforce a policy that blocks public access at the account level.

Match storage performance to the actual constraint. High-performance block storage is worth paying for when I/O wait genuinely dominates. It is wasted on a machine whose bottleneck is CPU, and it is very often bought for machines that are memory-constrained rather than storage-constrained.

If you are weighing providers rather than techniques, our cloud account catalogue lists what each one is strongest at, alongside the configurations available.

For the vendor’s own reference on the services involved here, see the UpCloud documentation.

Reading about storage behaviour only goes so far; measuring it on a live server goes further. We stock UpCloud accounts in a single configuration, and the cloud account catalogue covers nine other providers.

Questions people ask