Object storage vs a database for image files

Every website with uploads makes a storage decision early, and the common mistake is treating the database as a place to hold image bytes. Images and other browser-delivered files have different needs from the rows that describe them, and modern hosting gives you a separate store designed for exactly that job.

Where image files belong in the stack

An image is downloaded directly by the browser; a database row is queried by your application and rarely served byte-for-byte to a visitor. That difference drives the placement:

• Served by URL, cached by CDN: images live as files in object storage (the bucket-style store offered by AWS, Google Cloud, a dedicated object host, or a provider's media store), addressed by a URL and cached at the edge.
• Described in the database: the database stores the metadata you query for (path, width, height, alt text, licence, tags) but not the file bytes.
• Application-managed: your code decides when to read the file and when to read the row, instead of forcing a query to fetch a byte blob.

The real cost of image blobs in a database

Storing a 2 MB image as a BLOB works on a small site. It fails as you scale for concrete reasons:

• Backups and restores grow with every image, because the whole database file includes every byte of every uploaded media file. An INSERT ... VALUES cache of media makes a restore drill minutes longer.
• Queries and replication slow down, since index scans and streaming replication carry the image bytes with them.
• Delivery has no edge: the application must stream the blob to the browser, bypassing static-file caching and the CDN, which inflates origin load for images that could have been served from the edge.
• Storing and deleting are coarse: editing one thumbnail or promoting a derivative means a transaction on a large column instead of a file operation.

When a database is the right home

There are legitimate uses for bytes in the database. Store the file in the database when the blob is small, not browser-addressable, or must be atomic with its row: an encrypted document that must never be served publicly, a private original before combining, or a small profile avatar on a low-traffic app. In those cases the atomicity and one-server simplicity outweigh the scale cost. The moment the asset is a large photo a visitor loads, it belongs in object storage.

The split that scales

The standard pattern is: object storage holds the file, a CDN caches it at the edge, and the database holds only the reference plus metadata.

The derivative pipeline lives at the edge in the image CDN article, and serving many small files at scale is covered in the thumbnail guide. If you ever move the media store between systems, the large database export guide explains how to keep the metadata side separate from the file side.