Как спроектировать архитектуру БД несложного SaaS решения?

Дано:
Не сложное приложение (Flask+gevent+uwsgi+nginx+front на JS) которое задумано, как сервис (что-то вроде логгера с доп фишками)
В качестве БД на данный момент используется SQLite, но архитектура предусматривает переключение на почти любую SQL базу.
Это не соцсеть, поэтому over 9000 клиентов не будет. БД мягко говоря, простая. Около 20 таблиц.
Есть предложение для каждого клиента заводить отдельную базу данных. Вот доводы:
1. Чтобы более активные клиенты не мешали менее активным. Использование всяких лоад балансировщиков тоже, думаю, не наш масштаб..
2. Чтобы в случае краша данных страдали не все клиенты, а только те, у которых этот краш произошел.
3. В такой модели будет вполне достаточно SQLite, которая, как известно, не требует доп ресурсов на сервер БД. То есть сервис можно будет развернуть на более простом/дешевом железе.
Вопрос:
Хранить данные в одной или в нескольких базах?

Опыта создания саас решений у меня нет...Возможно мои доводы "притянуты за уши"...