Block storage vs object storage: what each one solves

1.00

Direct answer: block storage keeps data in blocks attached to a virtual machine, with low latency. It is the format for databases, the operating system volume and transactional workloads. Object storage keeps data as objects with metadata, accessed over an API, with nearly unlimited scale and a lower cost per GB. It is the format for files, media, backup and logs. NVMe is the fastest type of block storage, meant for demanding databases and high IOPS. Rule of thumb: data read and written all the time wants block or NVMe; data stored and accessed once in a while wants object.

The block storage vs object storage decision looks like an infrastructure detail, but it moves cost, performance and the very architecture of the application. And the right choice is almost never "the best storage". It is the storage that matches your data's access pattern. A database wants low latency and lots of IOPS. A file wants scale and cost per GB. When you separate these two worlds, you stop paying for fast disk to hold logs and you stop suffering latency by running a database in the wrong place.

This post is for whoever is designing (or reviewing) the storage layer and needs to decide what goes in each type. No filler: first the difference in one sentence, then each type, when to use it, a table and a four question checklist.

Block storage vs object storage: the difference in one sentence

Think of block storage as a cabinet of numbered drawers next to your desk. The operating system knows which drawer holds each piece of the file, grabs the pieces in order and assembles the data on the spot. It is fast and predictable. The limitation is that the cabinet is tied to that desk: it grows up to a point and serves one machine at a time.

Object storage is a different model. Picture a giant warehouse where each box carries a unique label describing its contents. You do not open the box to swap an item inside. You request the whole box by its label, receive it, and if you want to change something, you return a new box in its place. The warehouse has nearly infinite space, costs little per box and you reach it from anywhere with a request, which is the API. The trade is that fetching the box takes a moment longer than opening the drawer next to you.

The difference, then, is not quality. It is access pattern. The drawer next to you for what you touch all the time. The labeled warehouse for what you store and reach once in a while.

What block storage is

Block storage breaks data into fixed size blocks, each with its own address. These blocks are presented to a virtual machine as a volume, a "disk". What organizes the blocks into files and folders is the operating system's own file system, the same way it would with a local HD or SSD. To the application, it is a disk: it reads and writes without knowing that this lives on cloud infrastructure.

This model delivers what databases and transactional systems need: low latency and high IOPS (many read and write operations per second). That is why block storage is the natural home for:

Relational databases such as SQL Server, Oracle, MySQL, MariaDB and PostgreSQL.
The operating system volume and machine boot.
Off-the-shelf ERP systems under load, which write constantly to a database.
Cache, queues and any application that treats the disk as fast memory.

In practice, it is the disk where your managed database instance runs. At Optidata, these volumes use premium storage, with NVMe as the fastest tier (more on that below).

What object storage is

Object storage does not treat data as a disk. It treats it as an object: the content, plus metadata (who created it, when, type, tags), plus a unique identifier. These objects sit in buckets, in a flat space, without the folder hierarchy of a file system. You reach each object by API, over HTTP, with simple write and read operations (PUT and GET), from anywhere.

The gain is scale and cost. Object storage grows horizontally into petabytes without you provisioning a volume, and the cost per GB is low. It is the right format for data you store in volume and do not keep rewriting all the time:

Backup and data archiving.
Media: image, video and audio.
Logs, telemetry and data for a data lake.
Static files for a site or application (assets, downloads, documents).

There is a detail that changes the bill when you serve a lot of files: outbound traffic. On hyperscalers, reading and distributing these objects usually generates egress charges. At Optidata, Object Storage has no traffic charge, which keeps the cost of serving media and distributing files predictable. According to Optidata, the platform processes more than 15 petabytes, much of it in workloads that fit this model.

Where NVMe fits (and why it does not replace object storage)

NVMe is not a third category next to block and object. It is the fastest type of block storage. While older disks talk to storage through interfaces like SATA and SAS, NVMe talks to flash memory straight over PCIe, with many queues in parallel. The result is very low latency and very high IOPS.

Translated into workloads: NVMe is the volume you want under a demanding database, a transactional system with heavy concurrency or an off-the-shelf ERP at peak. Where every millisecond of disk access turns into response time for the user, NVMe makes a difference.

What NVMe does not do is solve the problem object storage solves. It is fast and expensive, tied to a machine, with scale limited to the volume. Storing millions of cold files on NVMe is a waste. The right read is this: NVMe for hot data, object storage for warm and cold data. One does not fight the other, each handles an access pattern.

When to use block, object or NVMe

Use block or NVMe when

A database will write to that volume.
It is the operating system disk or a machine's boot.
The application is transactional and latency sensitive (off-the-shelf ERP, order system, finance).
You need high IOPS and immediate response. For a heavy database under load, prefer NVMe.

Do not use object storage when

You are running a database's disk. The semantics and latency are wrong for that.
It is a machine's boot volume.
The application needs to rewrite pieces of the data all the time, rather than replace the whole file.

Use object storage when

You need to store backup, media, logs or files in large volume.
The data grows to tens of terabytes or more and cannot cost much per GB.
You want to reach and distribute the content by API, from anywhere.

Do not force block or NVMe when

The case is mass archiving that is rarely read. Fast disk here is money sitting idle.
The goal is serving static files at scale. Object does that better and cheaper.

Comparison table: block storage vs object storage vs NVMe

Criterion	Block storage	Object storage	NVMe (premium block tier)
Data structure	Fixed size blocks, with an address	Objects with metadata and a unique ID	Blocks, over flash on PCIe
How you access it	Attached to a VM, as a volume	By API/HTTP (PUT/GET), from anywhere	Attached to a VM, as a volume
Latency	Low	Higher	Very low
IOPS and concurrency	High	Not its strength	Very high
Scale	Limited to the VM's volume	Practically unlimited (petabytes)	Limited to the VM's volume
Cost per GB	Medium to high	Low	High
Editing data	At the block level, continuous	Replaces the whole object	At the block level, continuous
Typical case	Database, OS volume, off-the-shelf ERP	Backup, media, files, logs, data lake	Demanding database, high demand transactional
Where it trips	Storing files in bulk gets expensive	Not for a database disk or boot	Cost does not pay off for cold data

How to choose in four questions

A quick script to make the call by workload:

Is the data read and written all the time, in a hurry? If yes, block or NVMe. If it is stored and accessed once in a while, object.
Will a database or the machine's OS use this volume? If yes, block or NVMe, no debate. If it is files, media, backup or logs, object.
Will the volume grow to tens of terabytes or more of files? If yes, object solves scale and cost. If it stays around one VM's disk, block handles it.
Do you need minimal latency and lots of IOPS? A heavy transactional database or an off-the-shelf ERP at peak call for NVMe.

In most environments, the answer is not to pick one. It is to combine: database and operating system on block or NVMe, backup and media on object. The common mistake is dumping everything into the same type and paying dearly for it, whether on the invoice or in latency.

Pros and cons of each

Block storage

What it wins: low latency, high IOPS and disk semantics that any OS and any database understand without adaptation. It is predictable and simple to operate. Where it limits: scale stays tied to the machine's volume, cost per GB is higher and storing files in bulk here wastes an expensive resource.

Object storage

What it wins: nearly uncapped scale, low cost per GB and API access from anywhere. It is the best home for backup, media and file distribution. Where it limits: latency is higher, it does not run a database or a boot volume, and you replace the whole object instead of editing a piece. For hot, transactional data, it does not fit.

NVMe

What it wins: it is the fastest, with minimal latency and very high IOPS. It makes a real difference under a demanding database and a high concurrency system. Where it limits: high cost and volume scale. It makes no sense for cold data and it does not solve storing files in large volume, because it is still block.

FAQ

Is block storage faster than object storage?

For hot data, yes. Block storage delivers low latency and high IOPS because the volume is attached to the machine as a disk. Object storage is accessed by API, over HTTP, and prioritizes scale and cost, not access speed. That is why a database goes on block (or NVMe) and files go on object.

Can I run a database on object storage?

No. A database needs the disk semantics and the low latency that only block storage delivers. Object storage replaces the whole object on each write and answers by API, which does not match the constant, granular writing of a database. Run the database on block or NVMe and use object for backup and export.

Is NVMe the same as SSD?

Not exactly. SSD is the type of media (flash memory). NVMe is the protocol and interface through which that flash talks to the machine, straight over PCIe. A common SSD uses older interfaces like SATA. An NVMe volume uses flash over PCIe, with lower latency and higher IOPS. Every NVMe uses flash, but not every SSD is NVMe.

Is object storage always cheaper?

Per GB, usually yes, mainly for warm and cold data. But "cheaper" depends on the access pattern. For hot data, read and written all the time, the real cost shows up in latency and experience, not just in the price per GB. And there is outbound traffic: on a cloud that charges egress, serving a lot of files raises the bill. At Optidata there is no traffic charge, which keeps that cost predictable.

Which type should I use for backup?

Object storage is the natural choice for backup, for its scale and cost per GB. Add to that the offsite backup, which is keeping a copy of your data stored outside the main site, in case you lose the source environment. The usual combination is backup on object and, on top of that, an offsite copy.

Can I use block and object together?

Yes, and it is the most common. The standard design puts the database and operating system on block or NVMe and sends backup, media and logs to object. You pay for speed only where you need speed and pay for cheap scale where you need to store volume. That is how the storage layer stays balanced in cost and performance.

Need to design this layer by workload? Optidata tests it with you in a POC with no commitment, at a fixed price in reais and with database licenses included.