Убрали Redis из стека и положили кэш в PostgreSQL — кто так делал?

[mlapi1093]

Читал несколько статей про то что в 2026 году Redis для кэширования уже не так нужен, и что PostgreSQL с UNLOGGED таблицами вполне справляется с той же задачей. У нас сейчас Redis 7.2 для сессий и кэша API-ответов (TTL 5-60 минут), нагрузка ~3000 RPS пиковая. Кто реально выпиливал Redis и клал кэш в Postgres? Какие подводные камни? Хочется упростить инфру — меньше сервисов, меньше точек отказа.

[milana_flow]

Делал такое полгода назад для кэша с TTL. Схема простая: CREATE UNLOGGED TABLE cache (key TEXT PRIMARY KEY, value JSONB, expires_at TIMESTAMPTZ); — плюс индекс на expires_at для чистки. UNLOGGED означает что при крэше данные теряются, но для кэша это ок. Чистка через: DELETE FROM cache WHERE expires_at < NOW(); — крон каждые 5 минут или фоновый воркер. На 1000 RPS кэш-запросов latency p99 вышел около 3-4 мс, что для нашего случая абсолютно нормально. Redis давал 1-2 мс но при этом иногда зависал на RDB snapshot и давал спайки до 50 мс.

[rodion1629]

Не соглашусь что Redis больше не нужен. Для сессий и простого кэша — да, Postgres справится. Но если у вас pub/sub с тысячами подписчиков, Lua-скрипты, Streams, Sorted Sets для лидербордов — Postgres это плохая замена. Мы пробовали LISTEN/NOTIFY как замену pub/sub и уткнулись в ограничение: payload максимум 8000 байт, и нет гарантии доставки при высокой нагрузке. Пришлось вернуть Redis для этой части.

[savva6910]

@sec_researcher, Redis 8.6 кстати показал x5 throughput против 7.2 в бенчмарках (до 3.5M ops/sec с пайплайнингом). Если у вас уже Redis 8 — смысл убирать его вообще пропадает с точки зрения производительности. Переезд на Postgres-кэш оправдан если Redis у вас версии 6-7 и вы не хотите обновляться, или если инфра маленькая и лишний сервис реально в тягость.

[codeweb9669]

Мы сделали гибрид: Redis оставили только для rate limiting (там нужны атомарные инкременты и EXPIRE) и pub/sub. Всё остальное — UNLOGGED таблицы в Postgres. Итог: сэкономили на памяти (Redis жрал 12 GB под кэш), упростили бэкап-стратегию, меньше мониторить. Главный плюс — кэш можно джойнить с основными таблицами прямо в SQL, что иногда сильно упрощает логику.

[vadim9808]

@game_dev_andrey, Важный момент по UNLOGGED таблицам: они не реплицируются через streaming replication. Если у вас реплики для чтения и приложение иногда читает с реплики — кэш там будет пустой после рестарта или просто отсутствовать. Нужно либо писать кэш на каждый узел отдельно, либо мириться с cache miss на репликах. Для нас это было неожиданным сюрпризом в тестировании.