Multi-tenant SaaS: изоляция данных и модели биллинга — как выбрать архитектуру

Почему архитектура multi-tenant — краеугольный камень SaaS

Когда бизнес запускает B2B-платформу, вопрос изоляции данных клиентов и гибкой монетизации встаёт сразу. От выбора модели — одна база на всех или отдельная схема под каждого арендатора — зависят безопасность, масштабируемость и юнит‑экономика сервиса. В этой статье мы разберём ключевые подходы к изоляции, их влияние на биллинг и подскажем, когда стоит переходить от shared к schema-per-tenant, опираясь на практику разработки SaaS‑приложений.

Два полюса изоляции: schema-per-tenant vs shared database

В основе multi-tenant архитектуры лежит компромисс между простотой управления и изоляцией данных. Рассмотрим два классических подхода.

Shared database — единая схема для всех

Все клиенты хранят данные в общих таблицах, а принадлежность записей определяется по полю tenant_id. Это удешевляет развёртывание и обновления, но требует жёсткой фильтрации на уровне запросов и почти исключает возможность кастомизации схемы под заказчика.

• Минимальные инфраструктурные затраты — одна база данных.
• Простота CI/CD: один деплоймент обновляет сервис для всех.
• Риск: утечка данных из‑за ошибки в запросе без tenant_id.
• Сложность с аналитикой: разделение метрик требует дополнительной логики.

Schema-per-tenant — каждому клиенту своя схема

При регистрации нового тенанта создаётся отдельная схема в базе данных (например, PostgreSQL) или даже выделенная БД. Это даёт почти физическую изоляцию, упрощает бэкап, восстановление и соответствие требованиям вроде GDPR. Такой подход часто используют в продуктах, где клиенты требуют раздельного хранения данных, например, в CRM-системах или финансовых сервисах.

• Полноценная изоляция: запросы внутри схемы не нуждаются в tenant_id.
• Простое масштабирование: «тяжёлых» клиентов можно вынести на отдельные серверы.
• Индивидуальные миграции и обновления схемы для каждого тенанта.
• Выше накладные расходы на обслуживание множества схем.

Гибридные сценарии и каталожная изоляция

На практике редко встречается «чистый» shared или schema-per-tenant. Чаще используют гибрид: общая БД для общих справочников и отдельные схемы для критичных данных. Ещё один компромисс — подход «catalog-based»: общий сервер баз данных, но отдельная БД (catalog) на каждого клиента. Это упрощает миграцию между shared и schema-per-tenant, если стартап вырастает из монолита. При выборе архитектуры важно учитывать не только текущий MRR, но и будущий рост, так как миграция данных «на лету» в SaaS-сервисах с десятками клиентов может остановить весь бизнес. Здесь выручает опыт команд, которые проектируют облачные сервисы с учётом плавного масштабирования.

Модели биллинга: как архитектура диктует монетизацию

Схема хранения данных напрямую влияет на то, как вы выставляете счета. Разберём три популярные модели и их связь с изоляцией.

Плоская подписка (flat subscription)

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

Биллинг по пользователям или лицензии (per-seat)

Цена зависит от количества активных учётных записей или лицензий. Удобна при schema-per-tenant, потому что можно легко подсчитать использование и изолировать нагрузку на уровне клиента. Работает в CRM, системах документооборота и других B2B-сервисах, где ценность растёт с числом пользователей. Часто такую модель выбирают для многофункциональных корпоративных порталов.

Оплата по потреблению (usage-based)

Метрики: количество API-запросов, объём хранимых данных, часы использования. Требует детального учёта на уровне транзакций, что проще реализовать в schema-per-tenant, так как нагрузка метрики не смешиваются. Однако внедрить usage-based биллинг можно и в shared-архитектуре, если настроить агрегацию событий по tenant_id. В любом случае потребуется надёжный пайплайн для сбора и тарификации событий — это один из ключевых модулей при создании SaaS-приложений.

На что обратить внимание при выборе изоляции и биллинга

• Безопасность: если вы работаете с финансовыми, медицинскими или персональными данными, schema-per-tenant практически обязателен для аудита и комплаенса.
• Операционные расходы: администратору БД проще обслуживать 10 схем, чем 1000. Автоматизация создания и удаления схем — обязательная часть платформы.
• Onboarding клиентов: shared database позволяет запустить пилот за часы; schema-per-tenant требует автоматизированных скриптов миграции.
• Кастомизация: если клиентам нужны индивидуальные поля, отчёты или интеграции, shared схема быстро превращается в «лоскутное одеяло».
• План роста: если вы планируете выход на рынок США и ЕС, заранее закладывайте возможность физического разделения данных по регионам (data residency).

Часто задаваемые вопросы

Можно ли комбинировать shared database и schema-per-tenant в одном продукте?

Да, это распространённый гибрид. Например, общие справочники, шаблоны и данные для machine learning хранятся в общей схеме, а клиентские заказы, документы и финансы — в изолированной. Такой подход снижает накладные расходы и сохраняет безопасность критичных данных.

Какой биллинг выгоднее при старте SaaS?

На начальном этапе обычно выбирают плоскую подписку или per-seat — они проще в реализации и понятны клиентам. Usage-based требует более зрелой инфраструктуры учёта, но позволяет точнее монетизировать ценность и привлекать клиентов с небольшим чеком.

Сколько времени занимает миграция с shared на schema-per-tenant?

Всё зависит от объёма данных и сложности сервиса. В простых случаях — несколько недель с полным регрессионным тестированием. Для крупных B2B-платформ с историческими данными процесс может занять месяцы, включая этапы двойной записи и постепенного переключения клиентов. Поэтому архитектурное решение лучше принимать до запуска продукта.

Достаточно ли Row-Level Security (RLS) для shared database, чтобы пройти аудит безопасности?

RLS помогает отсечь чужие записи на уровне базы данных, но для строгих стандартов (PCI DSS, HIPAA) часто требует дополнительных мер: логирования обращений, маскирования данных, контроля доступа администраторов. Аудиторы могут потребовать физическую сепарацию, поэтому RLS не всегда заменяет schema-per-tenant.