Сжатие и хранение логов в PostgreSQL: баланс между стоимостью и поиском

Хранить все логи в горячей таблице удобно только на старте проекта. Когда объем вырастает, каждое решение начинает влиять на стоимость диска, резервное копирование и скорость запросов. Нужна стратегия, в которой часть данных остается доступной для быстрых расследований, а остальное переводится в более дешевый режим хранения.

Разделение слоев

Часто работает трехслойная модель: горячие данные за последние дни, теплые секции за последний месяц и архив, подготовленный для редких выборок. При этом структура таблиц остается совместимой, а маршрутизация запросов зависит от диапазона дат.

create table app_logs_hot partition of app_logs
for values from ('2026-04-01') to ('2026-05-01');

alter table app_logs_hot
    set (toast.compress = 'lz4');

Где появляется выигрыш

Сжатие больших текстовых полей, вынос редко используемых атрибутов в jsonb и удаление лишних дублирующих индексов снижают не только объем диска, но и стоимость записи.

Важно помнить

Экономия места не должна ломать расследование инцидентов. Перед изменениями полезно выписать несколько реальных запросов поддержки и убедиться, что после переноса в архив они все еще выполняются за разумное время.