So you've stored images in the db in production and had it work out fine?
I don't want to commit ten things a second. It would be a pretty read-heavy write-light load. Sounds like that would avoid one path of riskiness at least.
Many people answer a question like this: "How good is postgres at storing big blobs, relative to small things?" Postgres is indeed worse at storing large things. However, I think the most interesting question is something along these lines: "What's best, storing everything in Postgres and accepting that inefficiency for the big blobs, or implementing transactions, replication and/or backup with a part of the data in Postgres and the big blobs elsewhere?"
I'm awfully fond of having working backups, and postgres' performance problems with the blobs haven't been big enough that I've really noticed.
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.