Комментарии 2
Есть тёплое, а есть мягкое. А ещё можно на пути запроса поставить сначала тёплое, чтобы сделать его мягким.
Серьёзно, странное сравнение. Вот если бы вы написали свой in-memory сторадж для Postgres и сравнивали бы его с redis - хоть какой-то интерес был.
Redis не ориентирована на ACID-транзакции, так как приносит устойчивость в жертву скорости. Однако при желании она все же может удовлетворять всем требованиям стандарта для высоконадёжных систем.
ACID - это не только про надежность(durability), но еще и про атомарность, консистентность и изоляцию, что следует из названия. :)
И эти требования очень со скрипом реализованы в редисе - если 2 клиента будут одновременно модифицировать 2 записи в 2х разных коллекциях, то результат будет непредсказуемым, в отличии от Postgres, где при правильной настройке транзакций можно добиться того что один из клиентов вернет ошибку. И это было сознательным решением проектирования редиса, про которое надо просто знать и учитывать при работе с ним
Также, репликация "master-slave" с последующим чтением из реплик, чтобы разгрузить мастер-ноду реализована во все наверное сколько-нибудь популярных РСУБД уже лет 20 как.
В добавок к этому, в постгресе есть зачатки "шардинга из коробки", которых может хватить для ряда сценариев.
Так что в сухом остатке, я бы сказал что решение выбора типа СУБД следует непосредственно из бизнес-домена, и надо ответить на вопросы: нужны ли ACID гарантии или нет, возможен ли доступ по ключу в подавляющем большинстве сценариев(с точки зрения нагрузки), необходим ли шардинг или нет - и все станет ясно.
Матч Postgres vs Redis — как выбрать правильный инструмент для разных задач