Re: [GENERAL] Can PG replace redis, amqp, s3 in the future?

You can use postgresql for caching, but caches don't require the data
durability that a database offers, and can be implemented much more
efficiently.

I for one can understand Thomas' need for a single solution.
Just recently I needed a cache which was supposed to be set up in a SERIALIZABLE manner as in https://www.postgresql.org/docs/devel/static/transaction-iso.html#xact-serializable Available cache mechanisms would have produce erroneous results. So, I went for PG.

But it's still a cache, isn't it?

You can use postgresql to provide message queue services and it
does so reasonably well, particularly when the messages are generated within
the database. But it's not going to do so as efficiently, or be as easy to
monitor, to make highly redundant or to scale across a whole datacenter
as a dedicated message queue service.

You could use postgresql to store binary blobs, but it'd be a horrifically
inefficient way to do it. (Using postgresql to store the metadata, while
the content is stored elsewhere, sure).

Use the right tool for the job.

I think it's not as easy as ads and buzz words make us believe it is.

Especially when it comes to reinventing the wheel, I prefer a single solution. With the better JSON support, PG made NoSQL obsolete. I don't see why this cannot happen with blob storage and massive scale out. Just a matter of time, if you ask me.

Regards,
Sven