PostgreSQL в трекере: где БД начинает тормозить и как это лечить

PostgreSQL в трекере: где БД начинает тормозить и как это лечить

У трекеров проблема почти всегда одна и та же: таблицы кликов, конверсий и логов растут быстрее, чем желание админа жить. В итоге VACUUM не успевает, индексы пухнут, запросы на отчёты лезут в seq scan, а запись начинает спорить с чтением.

Что реально помогает:
— разносить горячие и холодные данные по партициям по дате;
— ставить составные индексы под реальные фильтры, а не «на всякий случай»;
— выносить тяжёлые агрегаты в отдельные таблицы, а не считать их на лету;
— держать autovacuum агрессивнее для write-heavy таблиц, иначе bloat съест диск и latency.

Для трекеров особенно важно не тащить всё в одну гигантскую таблицу. Отчётные окна почти всегда ограничены временем и источником трафика, значит партиционирование и правильный порядок колонок в индексе дают больше, чем попытка «прокачать железо». Под капотом всё устроено проще, чем кажется: Postgres любит предсказуемые запросы и ненавидит мусор в таблицах.

Отдельно следи за WAL и checkpoint: если у тебя много вставок, провалы по I/O часто идут не от CPU, а от плохо настроенной записи на диск. И да, pgbouncer здесь полезнее, чем лишний десяток соединений от каждого сервиса.

Контроль над стеком — это контроль над прибылью: сначала режь bloat и лишние запросы, потом уже покупай железо.