Выбор модели данных для многопользовательского SaaS влияет на безопасность, отчётность и производительность. Сравните tenant_id, отдельные схемы и отдельные базы с понятными компромиссами.
Многопользовательская архитектура (multi-tenancy) означает, что один продукт обслуживает многих клиентов (арендаторов), и каждый арендатор должен видеть только свои данные. Сложность в том, чтобы это соблюдалось постоянно: не только на одном экране, но и во всех API-вызовах, в админке, в экспортах и фоновых задачах.
Ваша модель данных влияет на повседневные операции больше, чем многие команды ожидают. Она формирует права доступа, отчётность, скорость запросов по мере роста и то, насколько опасной может быть «маленькая» ошибка. Пропустил один фильтр — и пошла утечка данных. Изолировал слишком сильно — и отчётность превратилась в рутину.
Есть три распространённых способа организовать модель данных для многопользовательского SaaS:
tenant_idДаже если вы строите визуально в no-code бэкенде, те же компромиссы остаются. Инструменты вроде AppMaster генерируют реальный код бэкенда и структуру БД из вашего дизайна, поэтому ранние решения по модели быстро проявятся в продакшен-поведении и производительности.
Представьте тикет-систему. Если каждая запись тикета содержит tenant_id, просто выполнить запрос «все открытые тикеты», но нужно везде контролировать фильтр по арендатору. Если у каждого арендатора своя схема или база, изоляция сильнее по умолчанию, но кросс-арендная отчётность (например, «среднее время закрытия по всем клиентам») потребует дополнительных усилий.
Цель — надёжная изоляция без ухудшения отчётности, поддержки и роста.
Не начинайте с теории баз данных. Начните с того, как продукт будет использоваться и что нужно для повседневной работы.
Насколько чувствительны данные и под какие правила вы попадаете? Здравоохранение, финансы и жёсткие клиентские контракты часто склоняют к более сильной изоляции (отдельные схемы или базы). Это снижает риск и упрощает аудит.
Нужна ли вам часто кросс-арендная отчётность? Если регулярно нужны метрики «все клиенты» (использование, доход, производительность), проще всего одна база с tenant_id. Отдельные базы усложняют задачу — придётся собирать данные из множества мест.
Насколько арендаторы будут отличаться друг от друга? Если арендаторы требуют кастомных полей, рабочих процессов или уникальных интеграций, отдельные схемы или базы уменьшают риск, что изменения «прольются» на всех. Если большинство арендаторов похожи, tenant_id остаётся аккуратным решением.
Что ваша команда реально сможет сопровождать? Чем сильнее изоляция, тем больше работы: бэкапы, миграции, дополнительные элементы инфраструктуры и места для ошибок.
Практичный подход — прототипировать два ведущих варианта, затем тестировать реальные проблемные места: правила прав, отчётные запросы и то, как изменения разворачиваются по мере эволюции модели.
Это самый распространённый вариант: все клиенты используют одни и те же таблицы, и у каждой записи, принадлежащей арендатору, есть tenant_id. Операционно это просто, потому что у вас одна база и один набор миграций.
Правило жёсткое: если строка принадлежит арендатору, она должна включать tenant_id, и каждый запрос должен фильтровать по нему. Как правило, в tenant-таблицы попадают пользователи, роли, проекты, тикеты, счёта, сообщения, метаданные файлов и таблицы связей, которые соединяют данные арендатора.
Чтобы уменьшить утечки, рассматривайте tenant_id как обязательный:
tenant_id обязательным (NOT NULL) в таблицах арендатораtenant_id (например, tenant_id, created_at)tenant_id в уникальные правила (например, уникальный email в пределах арендатора)tenant_id через каждый API и бизнес-процесс, а не только через формы UIВ PostgreSQL политики уровня строк (row-level security) могут быть сильной страховкой, особенно когда запросы генерируются динамически.
Справочные данные обычно делятся на две группы: общие таблицы (например, countries) без tenant_id и каталоговые таблицы, зависящие от арендатора (например, кастомные теги или пайплайны), которые включают tenant_id.
Если вы строите в AppMaster, простая привычка предотвращает большинство инцидентов: устанавливайте tenant_id из аутентифицированного пользователя перед любыми операциями создания или чтения в Business Process и придерживайтесь этого шаблона повсюду.
Именно права доступа определяют успех или провал многопользовательской модели. Выбор схемы данных меняет то, как вы храните пользователей, как ограничиваете запросы и как избегаете «внезапных» ошибок в админках.
При одной базе и tenant_id часто используют одну общую таблицу Users и связывают каждого пользователя с арендатором и одной или несколькими ролями. Главное правило остаётся прежним: каждое чтение и запись должны учитывать контекст арендатора, даже для «малых» таблиц, вроде настроек, тегов или логов.
При отдельных схемах обычно оставляют общий слой идентификации (логин, пароль, MFA) в одном месте, а данные арендатора хранятся в отдельной схеме на арендатора. Права частично превращаются в задачу маршрутизации: приложение должно направить запросы в правильную схему до выполнения бизнес-логики.
При отдельных базах изоляция самая сильная, но логика прав смещается в инфраструктуру: выбор правильного соединения с базой, управление учётными данными и обработка «глобальных» учётных записей персонала.
Во всех трёх подходах несколько практик постоянно снижают риск кросс-арендных ошибок:
tenant_id в сессию или claims токена и рассматривайте его как обязательныйВ AppMaster это обычно значит сохранять контекст арендатора сразу после аутентификации и переиспользовать его в API-эндпоинтах и Business Processes, чтобы каждый запрос оставался в нужной области. Агент поддержки должен видеть заказы только после того, как приложение установило контекст арендатора, а не потому что UI случайно отфильтровал список.
С одним tenant_id отчётность обычно проще. Глобальные дашборды (MRR, регистрации, использование) можно получить одним запросом по всем арендаторам, а отчёт по конкретному арендатору — тот же запрос с фильтром.
Проблема — производительность в масштабе. По мере роста таблиц один крупный арендатор может стать «шумным соседом», создавая много строк и нагрузку на записи, и замедляя общие запросы, если база вынуждена сканировать слишком много данных.
Индексация поддерживает эту модель в рабочем состоянии. Большинство tenant-ориентированных чтений должно использовать индекс, начинающийся с tenant_id, чтобы база могла перейти непосредственно к срезу данных нужного арендатора.
Базовый набор рекомендаций:
tenant_id в первой колонке (например, tenant_id + created_at, tenant_id + status, tenant_id + user_id)tenant_id — это приводит к медленным полным сканированиямТакже важно планировать ретеншн и удаления, потому что история одного арендатора может раздуть таблицы для всех. Если у арендаторов разные правила хранения, подумайте о мягком удалении с периодической архивацией по арендаторам или о переносе старых строк в архивную таблицу с ключом tenant_id.
При отдельных схемах вы всё ещё используете одну PostgreSQL-базу, но каждому арендатору выделяете свою схему (например, tenant_42). Таблицы внутри этой схемы принадлежат только этому арендатору. Это похоже на «мини-базу» для каждого клиента без накладных расходов множества баз.
Обычно глобальные сервисы хранят в общей схеме, а данные арендатора — в схемах арендаторов. Разделение обычно определяется тем, что должно быть общим для всех клиентов и что никогда не должно смешиваться.
Типичное разделение:
Эта модель снижает риск кросс-арендных JOIN-ов, поскольку таблицы живут в разных пространствах имён. Также проще сделать бэкап или восстановление одного арендатора, ориентируясь на его схему.
Миграции — сюрприз для многих команд. Когда вы добавляете новую таблицу или колонку, нужно применить изменение ко всем схемам арендаторов. При 10 арендаторах это ещё удобно. При 1000 — требуется процесс: отслеживание версий схем, запуск миграций пакетами и безопасное поведение при неудачах, чтобы одна сломанная схема не блокировала остальные.
Общие сервисы вроде аутентификации и биллинга обычно живут вне схем арендаторов. Практичный паттерн — общая аутентификация (таблица пользователей и таблица членств арендатора), а в схемах арендаторов хранятся бизнес-данные.
Если вы используете AppMaster, планируйте заранее, как модели Data Designer будут маппиться на общие и tenant-схемы, и держите глобальные сервисы стабильными, чтобы схемы арендаторов могли эволюционировать без ломки логина или платежей.
Отдельные схемы по умолчанию дают более сильную изоляцию, чем простая фильтрация по tenant_id, потому что таблицы физически разделены и права можно выставлять на уровне схемы.
Для отчётов по одному арендатору это удобно: запросы просты, потому что вы читаете только из таблиц нужной схемы без постоянных фильтров. Эта модель также поддерживает «особых» арендаторов, которым нужны дополнительные таблицы или кастомные колонки, без необходимости нагружать остальных.
Агрегатная отчётность по всем арендаторам — где схемы начинают мешать. Либо нужен reporting-слой, который умеет опрашивать много схем, либо поддержка сводных таблиц в общей схеме.
Распространённые паттерны:
Производительность обычно хороша для нагрузок на уровне арендатора: индексы меньше, и интенсивные записи в одной схеме реже влияют на другие. Компромисс — операционная нагрузка: provision нового арендатора означает создание схемы, запуск миграций и поддержание синхронности схем при изменениях модели.
Схемы подходят, когда нужна более строгая изоляция без стоимости множества баз или когда ожидается кастомизация на уровне арендатора.
При отдельной базе у каждого клиента своя база данных (или отдельная база на том же сервере). Это максимально изолированный вариант: если у одного арендатора данные испорчены, нагружены или неправильно настроены, вероятность воздействия на других минимальна.
Это хорошее решение для регулируемых сред (медицина, финансы, госструктуры) или для корпоративных клиентов, которые ждут строгого разделения, индивидуальных ретеншн-правил или выделенной производительности.
Онбординг становится процессом provisioning: при регистрации нужно создать или клонировать базу, применить базовую схему (таблицы, индексы, ограничения), безопасно создать и сохранить учётные данные и маршрутизировать запросы на правильную базу.
Если вы строите через AppMaster, ключевой выбор — где хранить каталог арендаторов (центральная карта арендатора к соединению с БД) и как гарантировать, что каждый запрос использует правильное соединение.
Апгрейды и миграции здесь — основная цена. Изменение схемы уже не «запустить один раз», а «запустить для каждого арендатора». Это добавляет работу и риск, поэтому команды обычно версионируют схемы и выполняют миграции как контролируемые задания с отслеживанием статуса для каждого арендатора.
Плюс в контроле: вы можете мигрировать больших арендаторов первыми, наблюдать за производительностью и затем постепенно выкатывать изменения.
Отдельные базы проще для рассуждений. Случайные чтения данных другого арендатора становятся маловероятными, и ошибка в правах обычно затрагивает только одного арендатора.
Производительность — также преимущество. Тяжёлые запросы, крупные импорты или «убегающие» отчёты у арендатора A не замедлят арендатора B. Это хорошая защита от «шумных соседей» и даёт возможность тонкой настройки ресурсов под арендатора.
Минус — отчётность. Глобальная аналитика по всем арендаторам становится самым сложным вариантом, потому что данные физически разнесены. Практически работают паттерны: копирование ключевых событий или таблиц в центральную reporting-базу, отправка событий в хранилище данных, выполнение per-tenant отчётов и агрегация результатов (когда число арендаторов небольшое) и разделение продуктовых метрик и данных клиентов.
Операционные затраты — второй большой фактор. Больше баз значит больше бэкапов, апгрейдов, мониторинга и инцидент-реакций. Также легко упереться в лимиты соединений, потому что у каждого арендатора может быть собственный пул соединений.
Большинство проблем многопользовательских систем — это не масштабные архитектурные просчёты, а мелкие упущения, которые разрастаются в баги безопасности, сложную отчётность и дорогую чистку. Многопользовательская архитектура работает, когда разделение арендаторов — привычка, а не фича, которую добавляют позже.
Типичная утечка возникает из-за забывчивости: одна таблица осталась без поля арендатора, особенно таблицы связей вроде user_roles, invoice_items или тегов. Всё выглядит нормально, пока отчёт или поиск не пройдёт через такую таблицу и не вытащит строки другого арендатора.
Ещё одна частая проблема — админ-панели, которые обходят фильтры по арендатору. Обычно начинается как «только для поддержки», а затем переиспользуется. No-code инструменты ситуацию не меняют: каждый запрос, Business Process и эндпоинт, читающий данные арендатора, должен иметь тот же scope арендатора.
ID тоже могут подвести. Если вы используете человекочитаемые ID, общие для всех арендаторов (например, order_number = 1001) и считаете их глобально уникальными, инструменты поддержки и интеграции начнут смешивать записи. Держите идентификаторы, зависящие от арендатора, отдельными от внутренних PK и всегда включайте контекст арендатора в поиски.
Наконец, команды недооценивают миграции и бэкапы по мере роста. То, что просто при 10 арендаторах, может стать медленным и опасным при 1000.
Быстрые проверки, предотвращающие большинство проблем:
Пример: агент поддержки ищет «инвойс 1001» и получает неправильный результат потому, что lookup пропустил контекст арендатора. Маленькая ошибка — большой эффект.
Перед тем как зафиксировать модель многопользовательской архитектуры, выполните несколько тестов. Цель — поймать утечки данных рано и убедиться, что выбранная модель работает при больших таблицах.
(tenant_id, created_at) и других распространённых фильтров) и намеренно замерьте хотя бы один медленный запрос, чтобы понимать, как выглядит «плохо».Чтобы конкретизировать тест отчётности, выберите два вопроса, которые вам точно понадобятся (один — по арендатору, другой — глобальный) и выполните их на тестовых данных.
-- Tenant-only: last 30 days, one tenant
SELECT count(*)
FROM tickets
WHERE tenant_id = :tenant_id
AND created_at \u003e= now() - interval '30 days';
-- Global (admin): compare tenants
SELECT tenant_id, count(*)
FROM tickets
WHERE created_at \u003e= now() - interval '30 days'
GROUP BY tenant_id;
Если вы прототипируете в AppMaster, включите эти проверки в Business Process (чтение, запись, удаление) и заведите два арендатора в Data Designer. Когда тесты пройдут на реалистичном объёме данных, можно принимать решение с уверенностью.
Компания на 20 человек запускает портал для клиентов: счёта, тикеты и простой дашборд. Ожидается 10 арендаторов в первый месяц и рост до 1000 в течение года.
На старте проще всего — одна база и tenant_id в каждой таблице с данными клиентов. Это быстро строится, удобно для отчётности и избегает дублирования настроек.
При 10 арендаторах главный риск — не производительность, а права. Одна забытая фильтрация (например, запрос «список счетов», где пропущен tenant_id) может привести к утечке данных. Команда должна централизованно обеспечивать tenant-проверки (в общей бизнес-логике или переиспользуемых API) и делать scoping неотклонимым.
По мере роста с 10 до 1000 арендаторов требования меняются. Нагрузки на отчётность растут, поддержка просит «экспортировать всё для этого арендатора», а несколько больших клиентов начинают доминировать по трафику и замедлять общие таблицы.
Практичный путь эволюции часто выглядит так:
Выбирайте простейшую модель, которая сегодня безопасно разделяет данные, и планируйте миграцию для «нескольких огромных арендаторов», а не оптимизируйте под это с первого дня.
Выбирайте, что нужно защищать в первую очередь: изоляция данных, операционная простота или масштабирование на уровне арендатора. Уверенность приходит после небольшого прототипа и попыток сломать его реальными сценариями прав и отчётности.
Простое руководство для старта:
tenant_id в каждой строке.Перед разработкой пропишите границы арендатора простым языком. Определите роли (owner, admin, agent, viewer), что каждая роль может делать и что означает «глобальные» данные (тарифы, шаблоны, логи аудита). Решите заранее, как должна работать отчётность: только по арендатору или «по всем арендаторам» для внутреннего персонала.
Если вы используете AppMaster, вы быстро прототипируете эти паттерны: моделируйте таблицы в Data Designer (включая tenant_id, уникальные ограничения и индексы, на которые опираются запросы), а затем принудительно применяйте правила в Business Process, чтобы каждое чтение и запись оставались в пределах арендатора. Если нужен ориентир по платформе, AppMaster указан как appmaster.io.
Практический финальный тест: создайте два арендатора (A и B), добавьте похожих пользователей и заказы и прогоните одинаковые потоки для обоих. Попробуйте экспортировать отчёт для арендатора A и умышленно передать ID арендатора B в те же эндпоинты. Ваш прототип считается «достаточно безопасным», когда эти попытки всё время проваливаются, а ключевые отчёты по-прежнему выполняются быстро на реалистичном объёме данных.
С какой модели базы данных многопользовательского SaaS лучше начать?По умолчанию выберите одну базу данных и tenant_id в каждой таблице, принадлежащей арендаторам, если вам важна простота операций и частая кросс-арендная аналитика. Переходите на отдельные схемы, когда нужна более жёсткая изоляция или кастомизация на уровне арендатора без множества баз. Отдельные базы данных выбирайте, когда соблюдение нормативов или требования заказчика диктуют жёсткое разделение и контроль производительности на арендатора.
Как предотвратить случайные утечки данных между арендаторами?Рассматривайте область арендатора как обязательную в бэкенде, а не как фильтр в UI. Сделайте tenant_id обязательным в таблицах, принадлежащих арендаторам, и всегда извлекайте его из контекста аутентифицированного пользователя, не доверяя клиенту. Добавьте страховку вроде PostgreSQL row-level security, если это подходит вашей архитектуре, и автоматизируйте тесты, которые пытаются получить доступ к данным другого арендатора, изменив только ID записи.
Какие индексы важны при модели одной базы с tenant_id?Делайте tenant_id первым столбцом в индексах, которые соответствуют вашим типичным фильтрам, чтобы база могла быстро перейти к срезу данных нужного арендатора. Базовый набор: (tenant_id, created_at) для временных представлений и дополнительные индексы вроде (tenant_id, status) или (tenant_id, user_id) для частых фильтров дашбордов. Также делайте уникальности с учётом арендатора (например, email уникален в пределах арендатора).
Что я получаю и теряю при использовании отдельных схем для каждого арендатора?Отдельные схемы уменьшают риск случайных кросс-арендных JOIN-ов, так как таблицы находятся в разных пространствах имён, и права можно назначать на уровне схемы. Основной минус — миграции: каждую схему нужно обновлять, и при большом числе арендаторов это становится процессной задачей. Это хороший компромисс, если нужна сильнее изоляция, чем tenant_id, но вы хотите управлять одной базой.
Когда действительно стоит использовать отдельную базу данных на арендатора?Отдельные базы минимизируют радиус поражения: падение производительности, неправильная настройка или повреждение данных, скорее всего, затронут только одного арендатора. Цена — операционная нагрузка: provision, бэкапы, мониторинг и миграции увеличиваются пропорционально числу баз. Также потребуется надёжный реестр арендаторов и маршрутизация запросов, чтобы каждый API-вызов использовал правильное соединение с базой.
Как делать «отчёты по всем арендаторам», если данные разделены по схемам или базам?С одной базой и tenant_id кросс-арендная отчётность самая простая — глобальные дашборды это просто запросы без фильтра по арендаторам. При разделении по схемам или базам глобальная аналитика обычно строится через копирование ключевых событий или сводок в общий reporting-стор по расписанию. Держите правило простым: продуктовые метрики — в reporting-слое, а данные арендаторов — изолированными.
Как безопасно предоставить доступ сотрудникам поддержки к аккаунтам арендаторов?Делайте контекст арендатора явным в инструментах поддержки и требуйте явного переключения арендатора перед просмотром записей. При использовании имперсонации логируйте, кто и когда получил доступ, и ограничьте такое использование по времени. Избегайте рабочих процессов поддержки, которые принимают только ID записи без контекста арендатора — именно так «счет 1001» превращается в утечку.
Как поддерживать кастомизацию арендаторов, не делая модель грязной?Если арендаторам нужны разные поля или рабочие процессы, схемы или отдельные базы уменьшают риск, что изменение для одного клиента повлияет на остальных. Если большинство арендаторов похожи, держите общую модель с tenant_id и решайте различия через настраиваемые опции: feature flags или опциональные поля. Главное — не создавать «почти глобальные» таблицы без чёткой ответственности за данные.
Как безопасно реализовать многопользовательскую модель в no-code бэкенде вроде AppMaster?Определите границу арендатора как можно раньше: где хранится контекст после аутентификации и как обеспечить, чтобы каждое чтение/запись его использовали. В AppMaster это обычно значит устанавливать tenant_id из аутентифицированного пользователя в Business Process перед созданием или запросом записей, чтобы эндпоинты не могли о нем забыть. Применяйте этот паттерн везде как переиспользуемую практику.
Какие тесты нужно прогнать перед окончательным выбором модели многопользовательской архитектуры?Создайте два арендатора с похожими данными и пытайтесь нарушить изоляцию, изменяя только ID записей при чтении, обновлении и удалении. Проверьте, что фоновые джобы, импорты и экспорты записывают данные в правильный контекст арендатора — эти пути легко пропустить. Также прогоните один отчёт на уровне арендатора и один глобальный админ-отчёт на реалистичном объёме данных, чтобы убедиться в производительности и правилах доступа.
21 янв. 2026 г.
1 мин
20 янв. 2026 г.1 мин
20 янв. 2026 г.1 минЭкспериментируйте с AppMaster с бесплатной подпиской.
Как только вы будете готовы, вы сможете выбрать подходящий платный план.
