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.
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 |