Object storage vs block storage

Introduction: Why Does Choosing the Right Storage Type Matter?

When you launch a website or application on a cloud server, one of the most important decisions you'll make is where to store your files and data. Many developers assume that any storage space works the same way, but that assumption is wrong. The choice between object storage and block storage can directly affect your website's speed, monthly costs, and even your application's architecture.

In this article, we'll examine the differences between these two storage types from three angles: their use cases, cost models, and exactly where you should keep your website's files. By the end, you'll have a practical decision-making guide based on your actual needs—not marketing hype.

What Is Block Storage and How Does It Work?

Block storage is exactly what you see on a regular hard drive or SSD. Data is divided into small, uniform pieces called blocks, and each block has an independent address. The server's operating system sees these blocks as a raw disk and can build a file system (such as ext4 or XFS) on top of it.

In the cloud environment, block storage is typically attached to your virtual server as a volume. For example, if you have a cloud server with a 50 GB disk, that disk is block storage. You can format it, partition it, and install any file system you want on it.

Key Features of Block Storage

• Low-level access: The operating system accesses blocks directly, so latency is very low.
• Resizability: You can usually increase the disk size without losing data.
• Server dependency: Block storage is attached to a specific server and cannot be shared across multiple servers simultaneously (except with special techniques like SAN).
• Ideal for databases: Due to low latency, it's the perfect choice for running MySQL, PostgreSQL, or Redis.

Practical Example: Database on Block Storage

Suppose you have an online store whose MySQL database runs on a cloud server. If you place the database on block storage, queries will execute at very high speed. But if you try to use object storage for a database, you'll run into serious problems—because object storage uses the HTTP protocol and its latency is tens of milliseconds, which is unacceptable for a database.

What Is Object Storage and How Is It Different?

Object storage is a storage model that keeps data as independent objects. Each object consists of three parts: the data itself, metadata, and a unique ID. Unlike block storage, there's no file system or traditional folder hierarchy here; instead, you interact with the service through an API (usually S3-compatible).

The most famous example of object storage is Amazon S3. In Iran, many cloud providers also offer S3-compatible services. ServerNet, as a cloud infrastructure provider, has also made object storage available for hosting static files and user content.

Key Features of Object Storage

• Unlimited scalability: You can increase your data volume without worrying about capacity. Costs are calculated only based on actual usage.
• Access via HTTP: Each object has a URL and can be served directly through a browser or CDN.
• Shareability: Multiple servers or services can access the same object simultaneously.
• High durability: Data is typically stored as multiple copies across different data centers.
• Ideal for static files: Images, videos, CSS and JavaScript files, and backups.

Practical Example: User Image Uploads

Suppose you have a photo-sharing website. Users upload hundreds of photos every day. If you store these images on your server's block storage, the disk will fill up quickly, and you'll constantly have to increase disk size. But with object storage, each photo becomes an object with a unique URL. You can use that URL directly in an <img> tag, and even put a CDN in front of it to optimize loading speed for users in Iran and abroad.

Cost Model Comparison: Which Is More Economical?

The cost models of these two storage types are completely different, and understanding them is crucial for making the right choice.

Block Storage Costs

With block storage, you typically purchase a fixed volume (e.g., 100 GB) and pay for it monthly. Even if you only use 10 GB, you pay for the full 100 GB. Additionally, IOPS costs (input/output operations per second) are usually calculated separately. If your server requires high IOPS, the cost can increase significantly.

Object Storage Costs

With object storage, costs are calculated based on three factors:

1. Storage volume: Only for the data you actually store.
2. Egress traffic: Data that leaves the service (e.g., when a user downloads an image).
3. Number of requests: Each PUT or GET has a negligible cost, but at scale, it can become significant.

For example, if you have 50 GB of images and generate 200 GB of egress traffic per month, your cost will roughly match that usage. But if you keep the same 50 GB on block storage, you'll pay for a 50 GB disk, and if you have high traffic, you might need more IOPS, which multiplies the cost.

Where Should You Keep Your Website Files? A Practical Guide

Now that you're familiar with the differences, let's provide a practical roadmap for decision-making. Base your decision on the type of data and how it's accessed.

Data That Should Be on Block Storage

• Databases: MySQL, PostgreSQL, MongoDB, and any other database that requires low latency.
• Temporary application files: Cache files, sessions, and files temporarily written to disk.
• Application executable files: PHP, Python, or Node.js code that needs to load quickly.
• Log files: Server logs that are continuously written.

Data That Should Be on Object Storage

• Public static files: Images, videos, CSS and JavaScript files that users download directly.
• User-uploaded files: Avatars, documents, attachments, and anything users upload.
• Backups: Database and website file backups that need to be retained for long periods.
• Media files: Podcasts, video courses, and audio files.

Hybrid Architecture: The Best of Both Worlds

In practice, most professional websites use a hybrid architecture. Here's how it works:

1. The database and application code reside on the cloud server's block storage.
2. Static and user-uploaded files are stored on object storage.
3. A CDN (Content Delivery Network) is placed in front of object storage to improve access speed across different regions of Iran.

This architecture gives you the best of both: high speed for the database and unlimited scalability for static files. To implement this architecture, you just need to change the file upload path in your application code to the object storage SDK. For example, in PHP, you can easily upload a file using the aws-sdk-php library:

<?php
require 'vendor/autoload.php';

use Aws\S3\S3Client;

$client = new S3Client([
    'version' => 'latest',
    'endpoint' => 'https://your-object-storage-endpoint.com',
    'credentials' => [
        'key'    => 'YOUR_ACCESS_KEY',
        'secret' => 'YOUR_SECRET_KEY',
    ],
    'region' => 'us-east-1',
]);

$result = $client->putObject([
    'Bucket' => 'my-bucket',
    'Key'    => 'uploads/photo-2024.jpg',
    'SourceFile' => '/tmp/photo.jpg',
    'ACL'    => 'public-read',
]);

echo $result['ObjectURL'];
?>

Common Mistakes and Troubleshooting Tips

Over the years of working with cloud infrastructures, I've repeatedly seen a few common mistakes that can cause trouble:

Mistake 1: Putting a Database on Object Storage

Some novice developers think that because object storage is cheaper, they can put their database on it too. This is practically impossible—databases require sub-millisecond latency, while object storage uses HTTP, which has a minimum latency of 50 to 100 milliseconds. The result: your website becomes extremely slow, and queries time out.

Mistake 2: Forgetting About Egress Traffic Costs

Many people only look at the cost per gigabyte of storage and ignore egress costs. If your website has 500 GB of egress traffic per month, this cost can exceed the storage cost itself. Solution: definitely use a CDN so traffic is served from the CDN side, not directly from storage.

Mistake 3: Incorrect ACL Configuration

When you upload files to object storage, they're private by default. If you forget to set the ACL to public-read, users won't be able to see images and will get a 403 error. This is a very common issue that usually shows up in production.

Troubleshooting Tip: Checking Latency

If your website is slow and you suspect the issue is storage-related, use the following commands to measure latency:

# For block storage (local disk)
dd if=/dev/zero of=/tmp/test bs=4k count=1000 oflag=dsync

# For object storage
curl -w "Time: %{time_total} seconds\n" -o /dev/null -s https://your-bucket.endpoint.com/file.jpg

If your object storage latency is above 200 milliseconds, the problem is likely with the network or CDN configuration.

Summary and Final Decision

Choosing between object storage and block storage isn't an "either/or" decision—it's an architectural decision. The rule of thumb is simple:

• If data needs fast, low-level access (databases, code, logs) → block storage
• If data needs high scalability and URL-based access (images, videos, backups) → object storage

For most Iranian websites, combining the two yields the best results. A cloud server with block storage for running the application and database, and object storage for static files and user content. If you're looking for a cloud infrastructure that offers both services, you can check out ServerNet's options; but more important than choosing a provider is correctly understanding your own needs.

Finally, always start with a small pilot. Upload a few test files to object storage, measure the latency, and make sure it's compatible with your needs. Then gradually migrate your real files. This is the lowest-risk way to move to a new architecture.