К сожалению, нет данных, почему базы удаленные и разделены на несколько. Это сильно влияет на ответ. Может быть это хотелка ваших клиентов, чтобы все данные хранились именно на их базах? Или по юридическим соображениям. Тогда имеет смысл вариант 3 — вы просто продаёте комлексный self-hosted продукт. Не думаю, что для админов составит много труда настроить системы мониторинга, сбора логов и бэкапа. Один раз написать скрипты и потом это автоматизировать.
Но если считать, что никаких ограничений нет, то я за вариант 2. Логичнее всего иметь одну базу, где каждая сущность имеет client_id, а в коде на уровне базовых классов ORM добавить фильтр по нему. С серверной стороны — шардинг по client_id:
— Всё будет работать быстро и масштабироваться горизонтально по мере роста клиентов
— Придётся архитектурно немного заморочить, но имхо меньше, чем в предложенных вами вариантах
— Можно иметь общий дефолтный ACL для всех клиентов с возможностью кастомизации для каждого из них (уверен, что это понадобится)
— Все данные в одной базе и при желании вы сможете сделать дэшборд для супер-админа, который будет уметь редактировать всё это хозяйство по всем клиентам сразу и онбоардить нового клиента: создать входной аккаунт для админа клиентской компании, установить дефолтные настройки и определить доступный набор фич. Если такое планируется, советую сразу продумать архитектуру, иначе будет потом крайне больно.
