Binary data in databases is usually not a great idea, but tolerable in low amounts.
I can't imagine storing images in a database, you're probably better off with a document store.
Relational Databases (well, the ones that I know the internals of) tend to have soft limits on row sizes, in PostgreSQL this is 8kb (which is very small for an image); to overcome this limitation Postgres uses what they call a TOAST table, which forces compression by default, which absolutely crumbles on binary data.
But, if it works, I'm not complaining- and I'm very certain that other such sites have worse architectural flaws in the beginning- this one is pretty easy to overcome if it becomes an issue and can be alleviated with aggressive caching of CDNs/varnish to buy you time if there's immediate issues. :)
If you were to go with PostgreSQL, wouldn't you store this in a large object, which is effectively stored outside of the actual table row? So, if you can store enough rows of meta data AND you provision enough storage, why wouldn't the database be able to do this. I don't imagine you want to put a primary key on the actual image data column (not possible with large objects, since the column just contains an "oid"). I'm not arguing for storing images in the database, I've seen it done either way, and done it myself either way, but I believe that it's an ongoing source of heated debate between proponents and opponents. I.e. not settled out of hand.
Large objects are _mostly_ an access method, the underlying implementation is staggeringly similar to TOAST.
> The large object implementation breaks large objects up into “chunks” and stores the chunks in rows in the database. A B-tree index guarantees fast searches for the correct chunk number when doing random access reads and writes.
You might try Foreign Data Wrapping.
In which case I still wouldn't because the database is going to be spending more time in doing round trips, better my application server does that, there's usually more of them.
Binary data in databases is usually not a great idea, but tolerable in low amounts.
I can't imagine storing images in a database, you're probably better off with a document store.
Relational Databases (well, the ones that I know the internals of) tend to have soft limits on row sizes, in PostgreSQL this is 8kb (which is very small for an image); to overcome this limitation Postgres uses what they call a TOAST table, which forces compression by default, which absolutely crumbles on binary data.
https://www.postgresql.org/docs/13/storage-toast.html
But, if it works, I'm not complaining- and I'm very certain that other such sites have worse architectural flaws in the beginning- this one is pretty easy to overcome if it becomes an issue and can be alleviated with aggressive caching of CDNs/varnish to buy you time if there's immediate issues. :)