Re: [GENERAL] Can PG replace redis, amqp, s3 in the future? - Mailing list pgsql-general

From Scott Marlowe
Subject Re: [GENERAL] Can PG replace redis, amqp, s3 in the future?
Date
Msg-id CAOR=d=1ii4GUZH8Vufxt=LnBatTc1MdBBWGonJkd5byZ03JnbA@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Can PG replace redis, amqp, s3 in the future?  ("Sven R. Kunze" <srkunze@mail.de>)
List pgsql-general
On Mon, May 1, 2017 at 2:59 PM, Sven R. Kunze <srkunze@mail.de> wrote:
> On 30.04.2017 16:25, Steve Atkins wrote:
>
> 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.

This brings up another subject, reliability. If PostgreSQL is fast
enough, and on stable hardware, it's often the preferred choice
because of its very good stability. Try running a big production noSQL
cluster and you'll find plenty of sharp corners in most. A lot of
times it's just easier to set up a pair of VMs (on good hardware) and
toss a pg db at the problem, esp if performance is a secondary
consideration, or not likely to tax pgsql's basic architecture.


pgsql-general by date:

Previous
From: Paul A Jungwirth
Date:
Subject: [GENERAL] Partitioning and Table Inheritance
Next
From: "Armand Pirvu (home)"
Date:
Subject: [GENERAL] data transformation and replication