Object Storage vs. Block Storage: What's the Difference?

If you're choosing infrastructure for a new application, "object storage vs block storage" is one of the first decisions you'll run into - and picking the wrong one can mean re-architecting later. They're not interchangeable: block storage and object storage are built for different access patterns, scale differently, have different durability models, and fit different workloads. This guide covers how each one actually works, where a third option (file storage) fits in, and how to decide which one your application needs.

What Is Block Storage?

Block storage splits data into fixed-size chunks called blocks, each with its own address, and presents them to a server as a raw volume - the same way a physical hard drive works. The operating system formats that volume with a filesystem (ext4, NTFS, XFS, etc.) and reads/writes blocks directly, without going through an HTTP layer.

Key characteristics:

• Low, predictable latency. Reads and writes happen at the block level, so there's no network API round-trip in the critical path.
• Single-server attachment (usually). A block volume is typically mounted to one server at a time - it's not designed to be shared concurrently across a fleet.
• Fixed capacity. You provision a volume of a specific size and resize it explicitly; it doesn't grow on its own the way a bucket does.
• Filesystem-level features. Permissions, directory structures, symlinks - everything a normal filesystem gives you, because it is a normal filesystem underneath.

This is the model behind AWS EBS, Google Persistent Disk, Azure Managed Disks, and traditional SAN/NAS arrays in on-prem datacenters. It's optimized for random, low-latency read/write access - exactly what a database or a boot volume needs.

What Is Object Storage?

Object storage manages data as whole, self-contained objects - a file plus its metadata plus a unique identifier - stored in a flat address space (usually organized into "buckets"). There's no filesystem hierarchy underneath; you access an object over HTTP via an API (PUT, GET, DELETE), not through block-level disk operations.

Key characteristics:

• HTTP API access. Every read and write is an API call, which means anything with network access can reach it - not just the one server it's mounted to.
• Effectively unlimited scale. Buckets aren't provisioned at a fixed size; you just keep adding objects.
• Rich, custom metadata. Each object can carry arbitrary key-value metadata alongside the data itself - useful for tagging, indexing, and workflow automation.
• Built-in versioning and replication (in most implementations). Keeping every version of an object, or replicating it to another endpoint, is usually a first-class feature rather than something you bolt on.

This is the model behind AWS S3 and every S3-compatible object store, including self-hosted ones like Alarik. It trades the low-latency random access of block storage for massive horizontal scalability, rich metadata, and access over a simple REST API from anywhere.

Where Does File Storage Fit In?

There's a third category worth knowing about: file storage (think NFS, SMB, or AWS EFS). Like block storage, it exposes a real filesystem with directories and POSIX-style permissions - but unlike block storage, multiple servers can mount and access it concurrently over the network.

File storage sits between the other two: it has the shared, networked access model of object storage, but the filesystem semantics of block storage. It's the right choice when several servers need to read and write the same files through a normal filesystem interface - shared configuration, some legacy applications, render farms - but it doesn't scale as elastically as object storage, and it's rarely what you want for something like user uploads or backups in a modern application.

Object Storage vs Block Storage: Key Differences

The core trade-off: block storage gives you speed and direct filesystem control at a fixed scale; object storage gives you effectively unlimited scale and simple HTTP access, at the cost of raw block-level performance; file storage compromises between the two when several servers genuinely need to share a real filesystem.

A Concrete Example: Saving a File

The clearest way to see the difference is to compare how an application actually writes data in each model.

With block storage, your application just writes to a mounted path - the storage layer is invisible to your code:

# Block storage: just a local filesystem path
echo "hello world" > /mnt/data/uploads/hello.txt

With object storage, your application calls an API, and the "path" is really a bucket and key:

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const client = new S3Client({
    endpoint: "http://localhost:8080", // Alarik or any S3-compatible endpoint
    region: "us-east-1",
    credentials: {
        accessKeyId: "YOUR_ACCESS_KEY",
        secretAccessKey: "YOUR_SECRET_KEY",
    },
    forcePathStyle: true,
});

await client.send(new PutObjectCommand({
    Bucket: "uploads",
    Key: "hello.txt",
    Body: "hello world",
}));

Same intent, completely different mechanism - which is exactly why you can't just swap one for the other mid-project without touching application code.

When to Use Block Storage

Reach for block storage when your workload needs:

• A database's data directory - PostgreSQL, MySQL, MongoDB, and similar all expect a real filesystem with low-latency random I/O.
• A VM or container's root disk - boot volumes need block-level access to work at all.
• Consistent, predictable low latency - anything sensitive to I/O latency spikes, like transactional workloads.
• Single-server, high-IOPS workloads - where the data genuinely only needs to live on one machine at a time.

When to Use Object Storage

Reach for object storage when your workload needs:

• User uploads and media - profile pictures, video, documents - anything served back over HTTP anyway.
• Backups and archives - cheap, durable, and doesn't need filesystem semantics.
• Static assets and build artifacts - anything a CDN or web app fetches by URL.
• Data accessed from multiple servers at once - object storage is inherently shared and networked; block volumes typically aren't.
• Anything that needs to scale without capacity planning - no resizing a volume, no running out of space on a mount.

A Typical Architecture Uses Both

Most real production systems don't pick one over the other - they use both, for what each is good at. A common pattern:

• The application's database runs on block storage, for the low-latency random I/O transactional workloads need.
• User uploads, generated reports, logs, and backups live in object storage, accessed over the S3 API from any service that needs them.
• The VM or container root disk is block storage; anything the app needs to persist beyond its own lifecycle goes to object storage instead.

They're complementary layers, not competing choices.

Self-Hosting Object Storage Without the Cloud Bill

One thing that's easy to miss: object storage doesn't have to mean a cloud provider's metered service. Because the S3 API is a standard, you can run your own self-hosted, S3-compatible object store on your own hardware or VPS - Alarik is one such option, free and open-source under Apache 2.0. You get the same bucket/object model and the same API your SDKs already expect, without a per-GB storage bill or egress charges, and without your data leaving infrastructure you control.

FAQ

Is Amazon S3 object storage or block storage?

Amazon S3 is object storage. It's accessed via an HTTP API, organizes data into buckets and objects rather than a filesystem, and is the reference implementation that S3-compatible tools like Alarik and MinIO also follow.

Is AWS EBS object storage or block storage?

AWS EBS is block storage. It's a network-attached virtual disk you mount to a single EC2 instance and format with a normal filesystem - the opposite access model from S3.

Which is cheaper, object storage or block storage?

Object storage is typically far cheaper per GB, since it's built for commodity, horizontally-scaled hardware rather than the higher-performance disks block storage requires. This is also true when self-hosting: a self-hosted object store can run on ordinary disks, while block storage performance depends heavily on your underlying drives.

Can object storage replace block storage?

Not for workloads that need real filesystem semantics and low-latency random I/O, like databases or VM disks. Object storage is a complement to block storage, not a drop-in replacement - use each for what it's good at.

Is NFS block storage or object storage?

Neither, exactly - NFS is file storage. It shares block storage's filesystem semantics (directories, POSIX permissions) but, like object storage, can be mounted by multiple servers at once over the network.

Does Kubernetes use object storage or block storage?

Both, for different things. Persistent Volumes backing stateful workloads (like a database StatefulSet) are typically block storage. Object storage is commonly used alongside Kubernetes for things like container registries, backups, and application-level file storage - usually accessed via an S3-compatible API rather than mounted as a volume.

Can I run object storage on-premises instead of in the cloud?

Yes. Any S3-compatible object store, including self-hosted options like Alarik, can run entirely on your own infrastructure - a single VPS, a home lab, or a full on-prem datacenter - while still speaking the same S3 API your tools and SDKs already use.

The Bottom Line

Block storage and object storage aren't competing technologies - they're different tools for different jobs, and file storage covers the gap where several servers need to share a real filesystem. If you're evaluating where to put user uploads, backups, or any data your application fetches over HTTP, that's squarely object storage territory.