Партиционирование против шардирования: одно слово, два разных понятия

Команда добавляет PARTITION BY RANGE (created_at) к своей таблице events и называет это «шардированием базы данных». Месяц спустя они удивляются, почему пропускная способность записи не улучшилась. Партиционирование и шардирование часто путают — они решают разные проблемы на разных масштабах.

Партиционирование: один Postgres, таблица разбита для pruning

Декларативное партиционирование таблиц (введено в PostgreSQL 10) разбивает одну таблицу на именованные подтаблицы — партиции, все живущие на одном экземпляре Postgres.

-- Один Postgres, одна машина, множество партиций
CREATE TABLE events (
  id BIGINT,
  tenant_id INT,
  created_at TIMESTAMPTZ,
  payload JSONB
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_01 PARTITION OF events
  FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');
CREATE TABLE events_2026_02 PARTITION OF events
  FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

Postgres получает две вещи от этого:

1. Partition pruning: запрос с WHERE created_at >= '2026-02-01' сканирует только нужные партиции, а не всю таблицу.
2. Мгновенное удаление для retention: удаление месяца данных — DROP TABLE events_2026_01 — мгновенно, без долгого DELETE, без bloat мёртвых строк, без массового VACUUM.

Критическое ограничение: партиционирование не увеличивает пропускную способность за пределы одной машины. Все записи всё равно идут на тот же primary Postgres; все чтения делят тот же CPU и RAM.

Шардирование: множество экземпляров Postgres, маршрутизация по ключу

Шардирование распределяет строки по N физически отдельным экземплярам Postgres. Каждый экземпляр держит подмножество данных. Записи и чтения для данного ключа шарда идут на Postgres того шарда — параллельный, независимый IO и CPU.

Как они сочетаются в продакшне

Реальные продакшн-системы обычно используют оба — партиционирование внутри каждого шарда:

Шард 0: экземпляр Postgres, хранящий tenant_id 1–500
  └── таблица events: PARTITION BY RANGE (created_at)
        ├── events_2026_01 (январские строки для клиентов 1-500)
        ├── events_2026_02 (февральские строки для клиентов 1-500)
        └── ...

Шард 1: экземпляр Postgres, хранящий tenant_id 501–1000
  └── таблица events: те же месячные партиции
        ├── events_2026_01
        └── ...

Ключ шарда (tenant_id) маршрутизирует трафик на нужный экземпляр Postgres. Внутри этого инстанса временная партиция означает: запрос WHERE tenant_id = 42 AND created_at >= '2026-02-01' обрезается до февральской партиции. Retention — DROP PARTITION events_2026_01 на каждый шард.

Опытная интуиция: партиционировать для того, что вы бы сделали на единственной машине в любом случае (retention time-series, pruning запросов для больших таблиц); шардировать только когда пределы пропускной способности и хранилища одного Postgres измерены и доказаны как реальное ограничение.