SaaS-платформу разумно проектировать не с вопроса «одна база или много», а с требований к изоляции клиентов, стоимости эксплуатации и скорости изменений. Для большинства новых B2B-продуктов подходит общая инфраструктура с явным tenant_id, централизованной авторизацией и автоматическими проверками границ тенанта. Отдельные схемы, базы или контуры нужны не «для солидности», а когда этого требуют регуляторика, объём нагрузки, договорные условия или цена возможной ошибки. Самая дорогая проблема здесь — не выбранный облачный сервис, а архитектура, в которой изоляцию нельзя проверить и безопасно изменить.
Что означает мультитенантность
Тенант — организация-клиент, чьи пользователи, настройки и данные обслуживает одна платформа. Мультитенантная система разделяет вычислительные ресурсы между клиентами, но обязана сохранять логическую или физическую границу их данных. AWS SaaS Lens рассматривает идентичность тенанта, онбординг, метрики и операции как связанные части SaaS-архитектуры [1]. Microsoft описывает мультитенантность как спектр моделей, а не единственный шаблон [2].
Это важное практическое различие. Можно развернуть отдельную базу для каждого заказчика и всё равно получить слабую SaaS-модель, если релизы выполняются вручную, тарифы зашиты в код, а мониторинг не показывает состояние конкретного клиента. И наоборот, общая база может быть приемлемой, если границы тенантов формализованы, тестируются и видны в аудите.
Вывод автора — непроверенный до подтверждения архитектором проекта. На старте полезнее оптимизировать не число изолированных ресурсов, а повторяемость операций: создание тенанта, назначение тарифа, миграцию, резервное копирование и удаление данных.
Нужна оценка архитектуры SaaS до разработки? Paladin Engineering может провести короткое обследование требований, выделить риски изоляции и подготовить варианты целевой схемы с последствиями для бюджета и эксплуатации.
Три базовые модели хранения данных
| Модель | Изоляция | Эксплуатация | Когда рассматривать |
|---|---|---|---|
Общие таблицы и tenant_id | Логическая | Проще централизовать | Ранний продукт, много небольших клиентов, единый релизный цикл |
| Отдельная схема на тенанта | Усиленная логическая | Сложнее миграции и контроль версий | Нужна дополнительная граница, число клиентов ограничено |
| Отдельная база или контур | Физическая или близкая к ней | Дороже автоматизация и наблюдаемость | Регуляторные требования, крупные клиенты, особые SLA или нагрузка |
Общие таблицы
В каждой доменной записи хранится tenant_id, а доступ строится вокруг контекста текущего тенанта. Плюсы — единая схема, понятные миграции, эффективное использование ресурсов. Главный риск — запрос без фильтра или неверно определённый контекст. Поэтому фильтрации только в UI или в коде контроллера недостаточно.
Для PostgreSQL дополнительной линией защиты может служить Row-Level Security. Документация PostgreSQL поясняет, что при включённой защите строки становятся доступны только по политикам, а при отсутствии политики действует запрет по умолчанию [3]. RLS не заменяет корректную авторизацию: владельцы таблиц и роли с BYPASSRLS имеют особенности, которые надо учитывать в модели угроз и тестах.
Отдельные схемы
Схема на тенанта облегчает некоторые операции экспорта и удаления, но быстро увеличивает число объектов. Каждое изменение структуры приходится применять ко всем схемам, контролировать частично завершённые миграции и поддерживать совместимость версий. Модель оправдана, если команда заранее построила автоматизированный lifecycle тенанта, а не рассчитывает обслуживать схемы вручную.
Отдельные базы или контуры
Наиболее сильная граница полезна для крупных клиентов и специальных требований. Но она переносит сложность в управление конфигурациями, секретами, обновлениями, резервным копированием и мониторингом. Если у каждого клиента появляется «почти своя версия», платформа превращается в набор заказных внедрений и теряет экономику SaaS.
Изоляция проходит через весь запрос
Надёжная схема начинается с единого источника контекста тенанта. После аутентификации сервер получает подтверждённые идентификаторы пользователя и организации. Нельзя доверять tenant_id, который клиентское приложение прислало в теле запроса. Далее контекст передаётся в бизнес-логику, запросы к данным, очередь задач, хранилище файлов и журнал аудита.
Минимальный контрольный список:
- членство пользователя в организации проверяет сервер;
- идентификатор тенанта есть во всех доменных сущностях, где он нужен;
- уникальные индексы учитывают тенанта, например
(tenant_id, external_id); - фоновые задачи несут подтверждённый контекст тенанта;
- пути объектов в файловом хранилище и правила доступа разделены;
- кэш не возвращает результат соседней организации;
- логи, метрики и трассировка позволяют расследовать инцидент по тенанту;
- интеграционные тесты пытаются получить чужую запись по известному ID;
- административный доступ ограничен, записывается и проверяется.
Полезно отдельно проверять «боковые» каналы: поиск, экспорт, автодополнение, уведомления, вебхуки, аналитические витрины. Именно они часто обходят общий слой репозитория и создают незаметный путь к данным другого клиента.
Наблюдаемость и «шумный сосед»
Средняя загрузка системы мало говорит о качестве SaaS. Нужно видеть потребление по тенантам: частоту запросов, задержки, объём очередей, ошибки, размер данных и дорогостоящие операции. Тогда можно отличить общий сбой от поведения одного крупного клиента.
Защита от «шумного соседа» строится слоями: лимиты на API, квоты на фоновые операции, раздельные очереди или приоритеты, таймауты, контроль сложных запросов. Для особо тяжёлого тенанта возможен перенос в выделенный пул без изменения пользовательской модели. Microsoft прямо предлагает рассматривать разные паттерны развёртывания и смешивать их по требованиям, а не искать один универсальный вариант [2].
Вывод автора — непроверенный до нагрузочного теста. Гибридная модель часто становится разумным целевым состоянием: основная масса клиентов работает в общем пуле, а отдельные организации переводятся в выделенные ресурсы по формальным критериям.
Как выбрать модель без преждевременного усложнения
Перед решением соберите ответы на шесть вопросов:
- Есть ли юридическое требование к физическому размещению или отдельному резервному копированию данных?
- Каков ожидаемый разброс нагрузки между самым маленьким и самым крупным клиентом?
- Нужны ли индивидуальные сроки обновлений или изменения схемы?
- Как быстро должна выполняться выгрузка и гарантированное удаление данных клиента?
- Какой простой допустим и кто несёт ответственность по SLA?
- Сколько изолированных контуров команда способна обновлять и наблюдать автоматически?
После этого сравнивайте не только стоимость ресурсов, но и стоимость операций: релиза, миграции, расследования, восстановления и поддержки. Прототип должен проверять самый рискованный путь — например, массовую миграцию схем или корректность RLS, — а не повторять весь будущий продукт.
Как Paladin Engineering может помочь
Мы проектируем веб-системы и корпоративные платформы от требований до эксплуатации. Для SaaS-проекта можем описать модель тенанта и ролей, спроектировать API и данные, собрать прототип критического сценария, настроить CI/CD, мониторинг и тесты изоляции. Если продукт уже работает, начнём с архитектурного аудита: найдём места, где контекст тенанта теряется, а ручные операции мешают масштабированию.
Смежные материалы и услуги: разработка веб-сервисов, интеграция информационных систем и разработка корпоративных порталов.
Хотите понять, нужна ли вам общая база или выделенные контуры? Напишите в Telegram или пришлите описание пользователей, данных, интеграций и требований к размещению. Мы подготовим варианты архитектуры и укажем, какие допущения надо подтвердить до оценки сроков.
FAQ
Можно ли безопасно хранить данные всех клиентов в одной базе?
Да, если логическая изоляция реализована во всех путях доступа и регулярно тестируется. Решение зависит от модели угроз и договорных требований; одна база сама по себе не означает ни безопасность, ни её отсутствие.
Достаточно ли добавить tenant_id во все таблицы?
Нет. Нужны проверенный контекст пользователя, серверная авторизация, корректные индексы, изоляция файлов, кэша и фоновых задач, а также негативные тесты доступа.
Заменяет ли PostgreSQL RLS проверки в приложении?
Нет. RLS — дополнительный барьер на уровне базы. Особенности ролей, владельцев таблиц и служебных процессов всё равно требуют отдельного проектирования.
Когда выделять отдельную базу?
Когда есть формальное требование к изоляции, восстановлению, размещению или нагрузке и команда способна автоматизировать жизненный цикл множества баз. Делать это только ради ощущения надёжности обычно дорого.
Можно ли сочетать разные модели?
Да. Платформа может обслуживать стандартных клиентов в общем пуле, а отдельных — в выделенном. Важно, чтобы маршрутизация и операции оставались едиными и проверяемыми.
Что проверить в MVP SaaS?
Онбординг тенанта, роли, невозможность межтенантного доступа, применение тарифа, резервное восстановление и наблюдаемость. Эти механизмы труднее и дороже добавлять после роста продукта.
Источники
- AWS, SaaS Lens — AWS Well-Architected Framework: https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-lens.html (дата обращения: 20.07.2026).
- Microsoft Learn, Architectural approaches for multitenancy: https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview (дата обращения: 20.07.2026).
- PostgreSQL Documentation, Row Security Policies: https://www.postgresql.org/docs/current/ddl-rowsecurity.html (дата обращения: 20.07.2026).
Комментарии