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

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: "Sven R(dot) Kunze" <srkunze(at)mail(dot)de>
Cc: Steve Atkins <steve(at)blighty(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Can PG replace redis, amqp, s3 in the future?
Date: 2017-05-08 18:54:12
Message-ID: CAOR=d=1ii4GUZH8Vufxt=LnBatTc1MdBBWGonJkd5byZ03JnbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, May 1, 2017 at 2:59 PM, Sven R. Kunze <srkunze(at)mail(dot)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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Armand Pirvu (home) 2017-05-08 19:46:32 data transformation and replication
Previous Message Paul A Jungwirth 2017-05-08 17:12:18 Partitioning and Table Inheritance