If databases can store images, why do engineers upload them to S3 instead?

If databases can store images, why do engineers upload them to S3 instead? I see this question a lot: “Isn’t it simpler to just store the image in the database?” Technically, yes, you can. Practically, you shouldn’t — at least not at scale. Databases are built to store and query structured data efficiently. Rows, columns, indexes, relationships. They’re optimized for fast lookups on small, structured records. Images are large binary blobs. Storing them directly in the database (as BLOBs) works, but it comes with real costs. Here’s why engineers avoid it: Database size explodes. A few thousand images can bloat your database from megabytes to gigabytes, slowing down backups, replication, and every query that touches that table. Performance degrades. Every query scanning that table now has to skip over large binary data, even if it doesn’t need it. Indexes get heavier. Caching gets less effective. Backups become painful. Backing up a database with embedded images means backing up the images every single time, even if they never change. Scaling gets expensive. Databases are built to scale reads and writes on structured data, not to serve millions of static files efficiently. S3 (or any object storage) is purpose-built for this. It’s designed to store large files cheaply, serve them directly over HTTP, scale horizontally without effort, and integrate with CDNs for fast global delivery. So the actual pattern most engineers use: Store the image in S3. Store the URL (or key) to that image in the database. The database stays lean and fast. The file storage handles what it’s built for. So instead of asking: “Can the database store this?” Ask: “Is this the right tool to store and serve this efficiently?” The goal isn’t to use one system for everything. The goal is to let each system do what it’s designed to do. Databases aren’t bad at storing images. They’re just not the right tool for the job.