Вертикальное масштабирование PostgreSQL упирается в потолок рано или поздно. Диск перестаёт тянуть IOPS, либо рабочий набор строк уже не влезает в память целиком, как ни добавляй RAM. Citus — расширение, которое раскладывает таблицы по нескольким узлам вместо одного, но снаружи остаётся обычным PostgreSQL: тот же psql, те же типы, тот же SQL.
Таблица создаётся как обычно, а дальше — одна функция:
CREATE TABLE github_events (event_id bigint, repo_id bigint, payload jsonb);
SELECT create_distributed_table('github_events', 'repo_id');
Citus хэширует значения repo_id и раскладывает строки по шардам. Каждый шард физически — обычная таблица PostgreSQL на одном из worker-узлов, а координатор хранит только схему распределения и маршрутизирует запросы к нужным шардам. Количество шардов задаётся заранее через citus.shard_count, и если две таблицы логически связаны (например, события и репозитории одного repo_id), их стоит объединить через colocate_with — иначе джойн между ними полетит по сети между узлами вместо локального выполнения на одной машине.
Смысл в этом есть, когда весь объём данных одного клиента или сущности естественно укладывается в один узел: мульти-тенантный SaaS с отдельным набором таблиц на тенанта, или real-time аналитика с параллельной агрегацией по шардам. Но если текущая нагрузка ещё помещается на одном сервере с нормальным NVMe и разумным shared_buffers, апгрейд железа почти всегда выйдет дешевле. Кластер — это уже не одна точка отказа, а несколько: свои бэкапы на каждый узел, перебалансировка шардов при росте, лишний слой, который может сломаться ночью.
#postgresql #citus
