В чем минусы при построении SaaS сервисов в подходе «на каждый аккаунт — отдельный экземпляр схемы БД»?

Question

[konstantin_levin]

Если рассматривать такие системы, как, например, облачные CRM - почему бы не создавать для каждого аккаунта отдельную базу (интересует mysql)? Плюсы на первый взгляд очевидны:
-дополнительный уровень защиты данных (нет вероятности, что при ошибке в программной части пользователь увидит "чужие" данные)
-проще масштабироваться шардингом - разносить далее БД разных аккаунтов по серверам
-упрощается программная часть - не надо в каждый запрос дописывать id_проекта
-проще управление индексами - при размещении индексов на диске будет сразу такой же эффект как при создании partitions индексов на каждый аккаунт (если не прав, просьба объяснить)
Понятно, что понадобится и отдельная схема для общих данных - учетные записи, биллинг и т.д.
Какие, все-таки, минусы такого подхода?

Answer 1

[sim3x]

-дополнительный уровень защиты данных (нет вероятности, что при ошибке в программной части пользователь увидит "чужие" данные)

нет

-проще масштабироваться шардингом - разносить далее БД разных аккаунтов по серверам

большей части юзеров никогда не понадобится такое

-упрощается программная часть - не надо в каждый запрос дописывать id_проекта

все зависит от архитектуры - в общем случае такой проблемы нет

-проще управление индексами - при размещении индексов на диске будет сразу такой же эффект как при создании partitions индексов на каждый аккаунт

что приведет к допраходам по рам - что для сервиса не сильно выгодно

Answer 2

[Пума Тайланд]

Зачастую так и есть, а в чем проблема у вас то конкретно?

Answer 3

[xeops]

А в суперадминке над аккаунтами SaaS вы как будете статистику собирать?