PostgreSQL для трекера: как не утонуть в таблицах кликов и конверсий

PostgreSQL для трекера: как не утонуть в таблицах кликов и конверсий

Если трекер пишет много событий, PostgreSQL убивает не объём, а плохая модель данных. Для потоковых записей держите отдельно:
— сырые события в append-only таблице;
— агрегаты по часам/дням;
— справочники кампаний, офферов, фидов.
Так вы не заставляете БД каждый раз пересчитывать историю ради одного отчёта.

Индексы ставьте только под реальные запросы. Для трекера обычно нужны составные по timestamp + campaign_id + offer_id, а не «всё подряд». Партиционирование по дате разгружает VACUUM и ускоряет удаление старых данных: дроп партиции всегда дешевле, чем массовый DELETE. Контроль над стеком — это контроль над прибылью.

Отдельно следите за bulk insert: батчи, prepared statements, минимум лишних триггеров. Если отчёты читают одно и то же, выносите тяжёлые JOIN’ы в materialized views или в таблицы предагрегации. Для горячих таблиц уменьшайте bloat: autovacuum не должен «догонять» систему, он должен работать на опережение.

Не храните в одной таблице и события, и аналитический мусор, и справочники. Владей своим софтом, а не арендуй его: правильная схема, партиции и точечные индексы обычно дают больше, чем попытка «ускорить PostgreSQL» магией параметров.