First Published: May 21 2020
Updated: Sept 7, 2026
Object storage is a way of storing data as self-contained objects in a flat pool, rather than as blocks on a disk or files in a folder hierarchy. Each object holds the data itself, a unique identifier, and metadata describing what the data is. There are no directories and no fixed structure, which is what allows object storage to scale to billions of items without slowing down.
That definition covers what object storage is. The more useful question, and the one that brings most people to this page, is where it actually belongs in an environment that already has storage. Object storage is not a replacement for the disk under a database. It is the right answer for a specific set of workloads, and the wrong answer for others, and the difference matters more than the architecture does.
This guide covers how object storage works, how it compares to block and file storage, what it costs once you account for the charges that are easy to miss, and why backup and recovery teams have become its largest practical users.
How object storage works
Every object gets a unique identifier when it is written. Applications retrieve it by asking for that identifier through an API, usually an S3-compatible one, rather than by navigating a path. There is no folder to traverse, so retrieval time stays roughly constant whether the pool holds a thousand objects or a billion.
Metadata is where object storage differs most from what came before. A file system records a limited, fixed set of attributes: name, size, dates, permissions. An object carries whatever metadata you attach to it, which might include retention policy, data classification, source system, or the date it becomes eligible for deletion. That metadata can then drive automation, which is why lifecycle rules and automated tiering are native to object storage and bolted on everywhere else.
Objects are also typically immutable in the practical sense. You do not edit an object in place. You write a new version. That behavior is inconvenient for a transactional database and extremely convenient for anything you need to prove has not been altered.
Object storage vs. block storage vs. file storage
The three models solve different problems, and most environments run all three.
| Block storage | File storage | Object storage | |
|---|---|---|---|
| Structure | Fixed-size blocks, no inherent structure | Hierarchical folders and paths | Flat pool of objects with unique IDs |
| Access | Attached to a server as a volume | Network share, SMB or NFS | API, usually S3-compatible |
| Metadata | Minimal | Fixed file attributes | Extensive and customizable |
| Editing | In place, byte level | In place | Write a new version |
| Scales to | Constrained by the volume | Degrades as the tree grows | Effectively unlimited |
| Best for | Databases, virtual machine disks, transactional workloads | Shared drives, collaborative documents, application file shares | Backups, archives, media libraries, logs, unstructured data at scale |
| Weakest at | Scaling out cheaply | Very large object counts | Anything needing low-latency in-place writes |
The short version: block storage is for data being actively changed, file storage is for data being actively shared, and object storage is for data being kept.
Where object storage actually makes sense
Backup and archive is the clearest case. Backup data is written once, read rarely, kept for a long time, and needs to be tamper-resistant. That profile matches object storage almost exactly, which is why every major backup platform now writes to object targets natively.
Unstructured data at volume is the second case. Media libraries, scanned documents, sensor output, log archives, anything where the item count runs into the millions and a file system would buckle under the directory structure long before it ran out of capacity.
Compliance retention is the third. When data has to be held for a defined period and demonstrably not modified during it, object lock and versioning give you a mechanism rather than a policy document.
Where object storage is the wrong answer is equally clear. Do not put a transactional database on it. Do not use it for a workload that rewrites the same data repeatedly, because every change writes a new object and you pay for both the write and the storage. And do not use it as a general-purpose file share, because the applications and the people using it expect paths and permissions that object storage does not natively provide.
What object storage costs
The advertised price of object storage is a per-gigabyte, per-month storage rate, and it is usually low enough to make object storage look dramatically cheaper than the alternatives. Storage is rarely the whole bill.
Three other charges shape what you actually pay.
Egress. Most providers charge to move data out of the platform. This does not matter when data sits untouched for years. It matters a great deal during a large restore, which is exactly the moment you are least interested in a surprise. Egress terms vary significantly between providers, and some charge nothing at all, so it is worth establishing the position before you commit rather than during an incident.
API operations. Requests to write, read, list and delete are typically billed per thousand or per ten thousand. Workloads that write many small objects can generate operation costs that rival the storage cost.
Retrieval and minimum retention on archive tiers. The cheapest storage classes trade cost against access, and the trade is more specific than most people expect. On Amazon S3, S3 Standard-IA and S3 One Zone-IA carry a 30 day minimum billable storage duration, S3 Glacier Instant Retrieval and S3 Glacier Flexible Retrieval carry 90 days, and S3 Glacier Deep Archive carries 180 days. Delete an object before that period is up and you are still charged for the remainder.
Retrieval times vary just as widely. S3 Glacier Instant Retrieval returns data in milliseconds, S3 Glacier Flexible Retrieval takes minutes to hours, and S3 Glacier Deep Archive takes hours, with archived objects requiring an explicit restore before they can be read at all. Other providers set different terms. The point is not that any of this is unreasonable, it is that a storage class chosen on price alone can quietly conflict with a recovery time objective agreed somewhere else in the business.
None of that makes object storage expensive. It makes the comparison more complicated than a per-gigabyte figure, and the right way to evaluate it is against your actual access pattern rather than against a rate card.
Object storage, immutability and ransomware
This is the part that has moved object storage from a storage decision to a recovery decision.
Ransomware operators go after backups. An attacker with sufficient access can encrypt or delete the backup repository alongside production, which turns a bad week into an existential one. Object lock changes that arithmetic. Written with a retention period applied, an object cannot be modified or deleted before that period expires, by an administrator, by a compromised account, or by an attacker holding valid credentials.
That is the immutable copy in the 3-2-1-1-0 backup rule, and object storage is the most common way organizations implement it. Veeam supports this natively against object storage repositories, and its documentation on immutability sets out how the retention period is applied and which repository types support it.
It is worth being precise about what immutability does and does not do. It does not prevent an intrusion. It does not stop data being exfiltrated. It does not help if the backups being written were already encrypted. What it does is guarantee that a known-good copy still exists when you need it, which is the difference between a recovery and a negotiation.
Choosing S3-compatible object storage
S3 compatibility has become the practical standard. If a platform speaks the S3 API, the backup software, applications and tooling you already run will generally work against it without modification, which keeps the decision reversible.
Beyond the API, the questions worth asking are about terms rather than technology. What is the egress position, and does it change during a large restore. Does the platform support object lock, and at what granularity. Where does the data physically sit, and does that satisfy the requirements you are subject to. What does the provider commit to on durability and availability, in writing. And when a restore is running at three in the morning, who answers.
Opti9 provides S3-compatible object storage as part of a managed backup and disaster recovery practice rather than as standalone capacity, which means the storage decision is made alongside the recovery objectives it has to support. As both an AWS Premier Tier Services Partner and a Veeam Platinum VCSP Partner, Opti9 designs object storage targets to work with the backup platform already in place rather than requiring one.
Frequently asked questions about object storage
What is meant by object storage? Object storage stores data as self-contained objects in a flat pool. Each object contains the data, a unique identifier, and customizable metadata. There is no folder hierarchy, and data is accessed by ID through an API rather than by file path.
Is Amazon S3 the same as object storage? No. Amazon S3 is one implementation of object storage, and because it became the dominant one, its API became the de facto standard. Many other object storage platforms are described as S3-compatible, meaning they accept the same API calls.
What are some examples of object storage? Amazon S3, Google Cloud Storage, Azure Blob Storage and Oracle Cloud Object Storage are the largest public examples. There are also independent and S3-compatible providers, and on-premises object platforms for organizations that need the model without the public cloud.
Is object storage cheaper than block storage? Per gigabyte stored, usually yes, and often substantially. Whether it is cheaper in practice depends on how often you read the data, how many API operations your workload generates, and what the provider charges for egress.
Can object storage be used for backups? Yes, and it is now one of the most common backup targets. Native support in the major backup platforms, combined with object lock for immutability, makes it well suited to both short-term backup and long-term retention.
What is object lock? Object lock applies a retention period to an object, during which it cannot be modified or deleted by anyone, including administrators. It is the mechanism most commonly used to create the immutable backup copy that ransomware recovery depends on.
Where this fits
Object storage on its own is a storage decision. Object storage chosen against a defined recovery time objective, with immutability configured and restores actually tested, is a recovery capability. The gap between those two things is where most organizations discover they have the first and assumed they had the second.
