Три рабочие модели
- Одна БД, колонка
tenant_id— быстрый старт, проще миграции. Подходит для десятков и сотен клиентов при строгих scope в Eloquent. - Схема на tenant — сильнее изоляция, сложнее DevOps.
- БД на tenant — максимальная изоляция, выше стоимость инфраструктуры.
На практике большинство MVP начинают с tenant_id + global scopes, а Spatie Laravel Multitenancy или кастомный TenantResolver подключают, когда появляются отдельные домены и биллинг.
Что заложить в MVP
- Middleware, который определяет tenant по поддомену, заголовку или сессии.
- Запрет на запросы без tenant-контекста в «общих» моделях.
- Отдельные очереди или префиксы jobs per tenant для тяжёлых задач.
- Аудит: кто и когда менял критичные настройки.
Типичная ошибка
Смешивать «глобальные» и «клиентские» сущности в одних таблицах без явных правил. Через полгода это превращается в дорогой рефакторинг. Лучше один раз описать границы в документации и тестах.
Готовы спроектировать мультитенант под ваш кейс? Напишите нам.