Single-tenant и multi-tenant SaaS: последствия для бизнеса
Продвинутое3 минРедакция Innovialabs
Коротко
Multi-tenant дешевле в эксплуатации и проще масштабируется, поэтому подходит для массового рынка. Single-tenant дороже, но упрощает продажи крупным клиентам с жёсткими требованиями к изоляции данных; многие продукты используют гибрид.
Короткий ответ
Multi-tenant — одна копия приложения и общая инфраструктура обслуживают всех клиентов, данные разделены логически. Single-tenant — у каждого клиента своя изолированная копия приложения и, как правило, своя база данных.
Для большинства SaaS-продуктов, особенно на старте и в сегменте малого и среднего бизнеса, разумный выбор по умолчанию — multi-tenant. Single-tenant оправдан, когда клиенты — крупные компании или регулируемые отрасли, готовые платить за изоляцию.
Сравнение по ключевым параметрам
| Параметр | Multi-tenant | Single-tenant |
|---|---|---|
| Стоимость эксплуатации на клиента | Низкая, ресурсы общие | Высокая, ресурсы выделенные |
| Обновления | Один релиз для всех | Нужно обновлять каждую копию |
| Изоляция данных | Логическая, зависит от качества кода | Физическая или на уровне инфраструктуры |
| Кастомизация | Ограничена настройками | Возможна глубокая |
| Онбординг клиента | Быстрый, самообслуживание | Требует развёртывания |
| Требования к хранению данных в конкретной стране | Сложнее выполнить | Проще выполнить |
Ценообразование
Multi-tenant позволяет предлагать недорогие тарифы и бесплатные пробные периоды: новый клиент почти не добавляет затрат. Это основа модели самообслуживания.
В single-tenant каждый клиент несёт собственные затраты на инфраструктуру и сопровождение. Поэтому цена обычно выше, часто есть минимальный порог контракта, а стоимость развёртывания закладывается в договор.
Продажи крупным клиентам
Крупные компании, банки и госструктуры часто предъявляют требования, которые проще закрыть в single-tenant:
- данные не должны физически соседствовать с данными других клиентов;
- хранение данных в определённой юрисдикции;
- контроль над окном обновлений;
- собственные ключи шифрования, отдельный аудит, интеграция с внутренней инфраструктурой.
Multi-tenant продукт тоже может пройти такие проверки, но потребует серьёзной работы над безопасностью, документацией и сертификацией.
Изоляция данных и риски
В multi-tenant главная угроза — утечка данных между клиентами из-за ошибки в коде, например, запроса без фильтра по tenant_id. Снижают риск:
- обязательная фильтрация на уровне ORM или базы данных (например, row-level security);
- тесты, проверяющие изоляцию;
- отдельные схемы или базы данных для каждого клиента внутри общей инфраструктуры.
-- PostgreSQL: строки видны только своему tenant
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
USING (tenant_id = current_setting('app.tenant_id')::uuid);
Есть и проблема «шумного соседа»: один активный клиент может замедлить работу остальных. Её решают лимитами и квотами.
Операционные затраты и масштабирование
Multi-tenant масштабируется как единая система: добавили мощностей — выиграли все. Мониторинг, бэкапы и деплой — один процесс.
Single-tenant масштабируется количеством копий. Без сильной автоматизации (инфраструктура как код, автоматический деплой, централизованный мониторинг) каждая новая копия увеличивает нагрузку на команду, и сотни инсталляций превращаются в отдельную операционную проблему.
Гибридный подход
Многие продукты совмещают модели:
- основная масса клиентов — в общей инфраструктуре;
- крупные клиенты — в выделенных окружениях на том же коде;
- общая кодовая база, разная конфигурация развёртывания.
Ключевое условие — единый код для всех вариантов. Ответвлённые версии под отдельных клиентов быстро становятся неподдерживаемыми.
Частые ошибки
- Выбрать single-tenant «на всякий случай» без реальных требований клиентов.
- Строить multi-tenant без изоляции на уровне данных и без тестов на неё.
- Разрешить кастомный код для отдельных клиентов в single-tenant.
- Не заложить идентификатор клиента в модель данных с самого начала — потом его добавлять дорого.