Schema-based шардирование и альтернативы мультиарендности

B2B SaaS с 200 корпоративными клиентами требует contractual data isolation — данные каждого клиента никогда не должны смешиваться в одной таблице. Row-based шардирование Citus помещает нескольких клиентов в один физический шард. Продуктовая команда спрашивает: существует ли более строгая модель изоляции, которую может обеспечить Postgres?

Четыре архитектуры мультиарендности

Citus 12 schema-based шардирование

Представленное в июле 2023, Citus 12 добавило schema-based шардирование: каждый клиент получает выделенную схему Postgres, и Citus распределяет схемы по воркерам.

-- Онбординг клиента: создать схему, Citus назначает её воркеру
CREATE SCHEMA acme;
CREATE TABLE acme.orders (id BIGINT, ...);
CREATE TABLE acme.users  (id BIGINT, ...);

-- Приложение: ограничить соединение схемой клиента
SET search_path TO acme, public;
-- Все последующие ссылки на таблицы разрешаются внутри схемы acme
-- Citus прозрачно маршрутизирует на воркер acme

Преимущества над row-based шардированием:

1. Не требуется общая колонка ключа распределения: любой запрос внутри схемы выполняется на её воркере — joins между любыми таблицами в одной схеме всегда локальные.
2. Схема — единица деплоя: CREATE SCHEMA для онбординга, DROP SCHEMA CASCADE для оффбординга, перемещение схемы между воркерами для ребалансировки.
3. Чистая изоляция клиентов: имена таблиц разные для каждой схемы — один клиент не может случайно прочитать данные другого.
4. Миграции на клиента: ALTER TABLE acme.orders ADD COLUMN ... затрагивает только эту схему.

Ограничения:

• Потолок числа клиентов: Citus рекомендует меньше нескольких тысяч схем. Метаданные схем загружаются в планировщик при каждом запросе; тысячи схем замедляют планирование.
• Кросс-клиентские запросы по-прежнему кросс-шардовые: аналитика по нескольким клиентам всё равно требует fan-out.
• Reference tables неприменимы внутри схем: lookup-таблицы должны быть в каждой схеме или доступны из общей схемы.

Оптимальная зона применения: B2B SaaS с 50–2000 корпоративными клиентами, где требуется contractual или regulatory data isolation.

Маршрутизация на уровне приложения

Полностью обойти Citus: код приложения поддерживает карту шардов (таблицу или сервис, маппящий tenant_id → connection_string) и явно маршрутизирует запросы.

// Пример: слой маршрутизации читает клиента из контекста запроса
const shard = await shardMap.get(req.tenantId);
const db = connectionPool(shard.connectionString);
return db.query('SELECT * FROM orders WHERE ...', [req.tenantId]);

Плюсы: явность, нет дополнительного продукта базы данных, максимальный контроль, логика маршрутизации на клиента (регион, тир тарифного плана). Минусы: каждая кросс-шард задача становится кодом приложения — joins, транзакции, fan-out, ребалансировка, failover. Слой маршрутизации — критическая инфраструктура первого уровня, которой вы теперь владеете.

Часто применяется, когда число шардов невелико (10–100) и запросы строго привязаны к клиентам. При 5000 клиентах со сложными запросами Citus обычно требует меньше инженерных усилий на многолетнем горизонте.

Database-per-tenant

Каждый клиент получает выделенную базу данных Postgres (или инстанс). Максимальная изоляция: клиенты буквально не могут делить никакую инфраструктуру на уровне базы данных.

Операционная модель:

• PgBouncer пул на (клиент, база данных)
• Бэкапы на клиентскую базу данных
• Минорные и мажорные обновления Postgres на клиентскую базу данных
• Миграции схемы, деплоируемые на клиента (или батчами)

Практический потолок: ~100–500 клиентов, прежде чем операционные накладные расходы начинают доминировать. Ниже этого значения database-per-tenant часто проще, чем Citus для регулируемых отраслей (финансы, здравоохранение), где contractual isolation — жёсткое требование.