Re: [GENERAL] Can PG replace redis, amqp, s3 in the future?
От | Scott Marlowe |
---|---|
Тема | Re: [GENERAL] Can PG replace redis, amqp, s3 in the future? |
Дата | |
Msg-id | CAOR=d=1ii4GUZH8Vufxt=LnBatTc1MdBBWGonJkd5byZ03JnbA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Can PG replace redis, amqp, s3 in the future? ("Sven R. Kunze" <srkunze@mail.de>) |
Список | 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 по дате отправления: