Object, Block & File Storage

So far, storage has meant structured records in a database. But plenty of real data is not rows at all: photos, videos, backups, log dumps, documents. Each of those has its own storage category with its own trade-offs, and choosing the wrong one is an expensive mistake. Putting a 5 MB photo inside a database row works in a demo and becomes painful at a million users. This chapter explains the three kinds of storage and the pattern that nearly every system uses for user uploads.

Think of three places to keep things. A warehouse where every box has a label: you ask for box 8841 and get the whole box, and if you want to change anything you hand back a replacement box, but the warehouse can hold more boxes than you could ever count. The drawer of your own desk, attached to you: you can change any single sheet at any time and it is very quick, but only you can use it. And a shared filing room that the whole office walks into, with folders inside folders, where many people can work on the same files.

• -The labeled-box warehouse is object storage: key in, whole blob out (Amazon S3 is the archetype).
• -The desk drawer is block storage: a raw disk attached to one machine (AWS EBS is the archetype).
• -The shared filing room is file storage: a folder tree many machines can use at once (NFS or AWS EFS).

Object storage is a flat namespace of keys and blobs. A key looks like photos/2026/cat.jpg, but the slashes are just part of the name, not real folders. You can put an object, get it, delete it, or replace it whole. There is no partial update. In return it scales to effectively unlimited size, costs the least per gigabyte of the three, and is built to be very durable: the major services keep many copies across locations, and one of them describes its design as losing, on average, one object in ten million about once every ten thousand years. It is the default home for user uploads, backups, logs and the static files served through a CDN.

The card below describes the component as it appears in the lab:

Block storage is a raw virtual disk attached to one machine, usually one at a time. It behaves like a real disk, so it supports fine-grained random reads and writes: change one page in the middle of a file and nothing else moves. That is exactly what a database needs for its data files, and what a server needs for its own boot disk. It is fast, but it is tied to one machine and you pay for the space you reserve, not the space you use.

File storage is a shared, hierarchical filesystem that many machines can mount at the same time, with the familiar folders, files and permissions. It is the right answer when several servers must read and write the same files, for instance a shared content directory or training data used by many machines. It costs more to run than object storage and does not scale to the same size.

• -User uploads, backups, static assets, anything written once and read as a whole: object storage.
• -A database's own disk, a machine's boot volume, anything needing fast random access on one machine: block storage.
• -Files that several machines must share with normal file semantics: file storage.

Whenever users upload files, the pattern is the same. Store the actual bytes in object storage, and store only a small reference (the object's key) in the database next to the record it belongs to. The database stays small and fast, and the storage layer does the heavy lifting. The diagram shows it:

There is one more refinement worth knowing. If every upload passes through your application servers, they spend their time copying bytes. A thousand uploads a minute of 5 MB each pushes 1,000 x 5 = 5,000 MB, which is 5 GB, through them every minute. Instead, the server hands the client a presigned URL: a temporary, signed address that allows one upload to one key for a few minutes. The client then sends the file straight to object storage, and the application only receives a small notification that it arrived.

• -The client asks your API for permission to upload a file.
• -The API creates a presigned URL for a new key and returns it.
• -The client uploads the file directly to object storage using that URL.
• -The client tells the API it is done, and the API saves the key in the database.