Why You Shouldn't Store Images in a Database

In Postgres, the default size of a Page is 8KB.

Whenever the system needs to read or write data, it doesn't read individual bytes; it loads that entire 8KB Page from the disk into the RAM (Buffer Pool). This architecture is highly optimized for structured data (short strings, integers, booleans) because hundreds of rows can fit perfectly within a single Page.

Let's do some simple math. Suppose you allow a user to upload a 2MB image.

*(Note: Postgres uses a mechanism called TOAST to chunk large data, but the physical reality remains: allocating hundreds of pages for a single file).*

Instead of a single Page holding hundreds of user records (names, emails, statuses), the system now has to consume 256 Pages just to hold one single image.

Consuming 256 Pages is not merely a Storage Cost issue. The worst consequences occur in the system's RAM (Shared Buffers / Buffer Pool).

A database operates blazingly fast because it keeps frequently accessed data (hot data) and Indexes in RAM. This RAM is strictly limited. When a query is executed to fetch a list of users along with their images, Postgres is forced to pull thousands of image-heavy Pages from the disk into the RAM.

This phenomenon is called Buffer Pool Pollution. It leads to:

Blob Storage (Binary Large Object Storage) like Amazon S3, Google Cloud Storage, or Azure Blob is designed with an entirely different philosophy. They do not care about strict row structures, Indexes, or Pages. They are flat storage systems heavily optimized for unstructured data at a fraction of the cost of a relational database.

In a standard, scalable system, we apply a decoupled model:

Slack's "Green Dot" Problem: The Nightmare of Real-Time Architecture

Displaying an online status seems basic, but it becomes an infrastructure nightmare at scale. Discover how Slack restructured its Pub/Sub model to balance real-time accuracy with server costs.