Earlier quoted context omitted.
>Yes, it's a database. That's where you're meant to put DATA. Most (all?) large-scale high-volume image storage architectures I'm aware of do not store billions of images as blobs in a database. Instead, they typically store the images as files . The database only holding metadata info and a pointer to the image filename location (or url if using AWS S3 or CDN). E.g. Facebook is one of the largest MySQL sites (if not…
I understand that postgres is pretty decent at storing large binary data though? I've been meaning to investigate trying storing images in postgres on a hobby web project where it could be convenient; I'd still want to make sure I was streaming bytes from postgres to the client, not loading the whole image into memory and only once fully loaded sending it to the client. Looking at the pg API's for my language/platfor…
If you want to commit ten things every second all week, don't transfer so much data in a single transaction that you hold any important locks for half a minute. And if you use replication, test while replicating.
If the blobs you store are small enough to not disturb your commit rate, then pg's drawbacks are IMO smaller than those of the alternatives, particularly if you want some sort of commit that returns when both image data and something else have been committed.