Недавний эксперимент в Kubernetes-кластере снова поднял старый вопрос: если у нас уже есть PostgreSQL, а Redis — это дополнительная зависимость, можно ли просто кэшировать прямо в Postgres?
Автор статьи Redis is fast – I’ll cache in Postgres проверил это на практике и сравнил оба подхода.
Что показали тесты
🔴 Redis оказался ожидаемо быстрее:
- ⚡ Запросы в секунду — Redis стабильно держал более высокую пропускную способность как на чтении, так и на записи.
- 🕒 Задержки — в миллисекундах разница небольшая, но Redis чаще выигрывал.
- 🔌 Ресурсы — Redis использовал около 1280mCPU и 4,3 ГБ RAM, не упираясь в лимит CPU.
🔵 PostgreSQL показал себя так:
- 🖥 Нагрузка на CPU — база данных стабильно упиралась в два ядра, выделенные в k8s, и держала использование процессора на 100%.
- 🧮 Память — до 6 ГБ RAM.
- 📦 Нелоггируемые таблицы ускорили операции записи, но почти не помогли при чтении.
Авторский вывод
Redis выигрывает как специализированный инструмент. Он уже умеет работать с TTL, оптимизирован под кэш и даёт стабильный результат. Но!
Автор честно признаёт:
- Если проект маленький или «разогнанный» кэш не нужен, PostgreSQL может быть достаточно быстрым.
- В реальных сценариях 7 425 запросов в секунду (такой результат показал Postgres на старом железе) хватит на большинство задач.
- Убирать зависимость от Redis ради простоты инфраструктуры иногда важнее, чем «выжать максимум».
Моё мнение
Мне нравится этот эксперимент тем, что он показывает реализм подхода.
🚀 В мире стартапов и небольших сервисов очень часто «стреляют» советы уровня «ставьте Redis, иначе всё сломается». Но на деле:
- 99% проектов никогда не достигнут нагрузки, где Redis становится необходимостью.
- PostgreSQL — универсален. Добавил кэш-таблицу с TTL и cron-очисткой — и живёшь спокойно.
- Настройка Postgres (shared buffers, work_mem, autovacuum tuning) может ещё сильнее сократить разрыв с Redis.
⚖️ Однако важно понимать: Redis — это память, Postgres — это диск. Архитектурно Redis всегда будет быстрее в ин-мемори сценариях. Но если у вас «монолит» на Postgres, и нужно минимальное количество сервисов — компромисс оправдан.
Интересный технический момент
Redis здесь работал практически «в полсилы» из-за того, что HTTP-сервер в тестах стал узким местом. То есть его реальная производительность могла быть ещё выше. Это напоминает важный урок: узкое место почти всегда не там, где мы ожидаем.
Итог
Redis остаётся «золотым стандартом» кэширования. Но PostgreSQL способен покрыть часть задач, особенно если важна простота архитектуры и отказ от лишних сервисов. Как всегда в инженерии: всё зависит от контекста.
🔗 Источники: