Ошибка в архитектуре Multi-tenancy на старте SaaS приводит к утечке данных 100% клиентов или полной остановке сервиса при попытке масштабирования с 10 до 100 компаний. В no-code среде, где вы не контролируете уровень сервера, разделение данных — это единственный барьер между вашим продуктом и судебным иском о нарушении конфиденциальности.
Три стратегии изоляции данных в SaaS
Существует три подхода к организации многопользовательского доступа: Database-per-tenant (отдельная БД для каждого), Schema-per-tenant (отдельная схема) и Shared Database (общая таблица с идентификатором TenantID). В no-code инструментах вроде Bubble или FlutterFlow реализован почти исключительно Shared Database, так как платформы не дают создавать динамические БД на лету.
Кейс: При попытке реализовать Schema-per-tenant через внешнюю PostgreSQL в связке с No-code фронтендом, стоимость поддержки инфраструктуры вырастает в 3-5 раз из-за сложности миграций. Для MVP с чеком $20-50/мес за пользователя такая архитектура экономически бессмысленна.
Экспертный вывод: Для 95% no-code SaaS единственным рабочим вариантом остается Shared Database с жесткой фильтрацией по TenantID на уровне каждого запроса.
Механика фильтрации и риск «утечки» данных
Главная ошибка новичков — фильтрация данных на стороне фронтенда. Если вы загружаете все записи в браузер и скрываете лишнее через CSS или простые фильтры, любой пользователь через консоль разработчика увидит данные конкурентов. Правильный путь: фильтрация на уровне сервера (Server-side filtering). В Bubble это Privacy Rules, во FlutterFlow — Security Rules в Firebase.
Пример: В приложении для учета финансов запись должна иметь поле `company_id`. Запрос к БД должен выглядеть так: `SELECT * FROM transactions WHERE company_id = current_user.company_id`. Если пропустить это условие хотя бы в одном API-запросе, вы рискуете данными всех клиентов.
Экспертный вывод: Безопасность данных в no-code SaaS строится не на надежности платформы, а на архитектурном запрете доступа к записям, где `TenantID` не совпадает с ID текущего сеанса.
Масштабирование и лимиты записей
Shared Database создает проблему «шумного соседа», когда один клиент с 100 000 записей замедляет работу системы для десяти клиентов по 100 записей. В no-code это проявляется в росте времени отклика API с 200 мс до 2-3 секунд. Большинство платформ (например, Xano или Airtable) имеют жесткие лимиты на количество строк (от 10к до 100к в базовых тарифах), после которых цена растет экспоненциально.
Сравнение: Использование внутренней БД Bubble бесплатно до определенного объема Workload, но внешняя БД (Xano) при объеме данных от 50 000 записей сокращает время отклика на 30-40% за счет индексации по TenantID.
Экспертный вывод: Если ваш SaaS предполагает генерацию более 5 000 записей на одного клиента в месяц, выносите базу данных за пределы no-code конструктора на выделенный бэкенд с поддержкой индексов.
Связь архитектуры с тарифными планами
Архитектура БД должна поддерживать разные уровни доступа (Tiers). Это реализуется через таблицу `Subscriptions`, где для каждого `TenantID` прописан лимит (например, до 5 пользователей или 1 ГБ хранилища). При попытке создать запись сверх лимита, бэкенд должен возвращать ошибку 403 или перенаправлять на страницу оплаты.
Практика: Интеграция с биллингом требует синхронизации статуса оплаты. Если Stripe присылает webhook об отмене подписки, статус в таблице `Tenants` меняется на `inactive`, и все Privacy Rules должны мгновенно заблокировать доступ к данным, не удаляя их (для возможности восстановления).
Экспертный вывод: Не делайте проверку тарифа на фронтенде. Только серверный запрос к таблице подписок перед выполнением любого действия — это единственный способ избежать «бесплатных» пользователей в вашем SaaS.
Вывод
Для запуска SaaS на no-code выбирайте модель Shared Database с обязательной серверной фильтрацией по TenantID. Избегайте хранения данных в Airtable для серьезных проектов из-за отсутствия полноценных прав доступа на уровне строк. Начинайте с внутренней БД платформы для проверки гипотез, но при достижении 50 платящих клиентов или 100 000 записей переходите на связку FlutterFlow/Bubble + Xano/PostgreSQL. Это обеспечит безопасность и позволит избежать полной переработки архитектуры при миграции на код.