Почему не используют NoSql решения на каждого пользователя?
Ежемесячно почтой пользуются более 27 миллионов пользователей.
вот яндекс например (это только те кто пользуется, а сколько зарегистрировано за 20 лет неизвестно)

А теперь представьте: придумали новую функцию и надо накатить миграцию в базе данных. 
Добавить столбец или создать таблицу там какую-нибудь очень нужную.
Это надо 27 миллионов раз накатить миграцию.
Очень эффективно получится? Деплоить по одному апдейту в месяц или вроде того)

А если в принципе надо переехать куда-нибудь и перенести данные, тоже собирать в кучу как-то 27 миллионов разных баз. Или даже сделать бекап например.

Про всякие аналитики, статистики и т.п. можно вообще не думать, неизвестно как можно будет подключиться к такому количеству баз чтобы сделать какую-то общую статистику.

А если место на сервере кончается например где у нас хранится сколько-то пользователей каждый в своей базе, получается надо полностью все данные одного пользователя переносить на другой сервер, а не просто сделать репликацию и шардинг чтобы данные лежали на N количестве серверов и такой проблемы не возникало.

а там данных на одного пользователя не больше миллиона значений
от балды цифра, а если у меня 2 миллиона? А если 3? Каждый раз всё переделывать когда появляется пользователь который выходит на ваши рамки?
А когда один пользователь перестанет влезать на один сервер?
А что если 10 пользователей занимают диск целого сервака, а нагрузки при этом никакой не создают - сервер простаивать будет просто так?

Ну в общем можно много чего еще такого придумать.
Это не поддерживаемо, не масштабируемо, неудобно ни с какой стороны.
Если бы было по другому так бы все делали.
Я думаю что твоя идея не лишена смысла. Можно на каждого пользователя поднимать экземпляр БД.
Что здесь хорошо изоляция и безопасность. Что здесь плохо обилие linux-процессов на каждого пользователя. Например если у тебя чат на 10 000 человек - то поднять столько-же процессов на одном хосте сложнее.  Любые операционки имеют какой-то минимальный футпринт памяти и ресурсов ОС на процесс. И переключение. Планировщик будет бегать между 10 тыщ процессов обслуживая их события. Что еще может быть плохо. Администрирование этого грида приложений. Бэкап проще делать имея 1 сущность процесса и 1 лог ошибок. А что делать с 10 тыщами логов. Отвественый девопс должен как-то просмотреть все логи? Или уже начать писать автоматизацию бэкапов. Кажется пустяк - но ты сядь и просто попробуй сам это сделать. Или мониторинг. Как проверить что все 10 тыщ не содержат в логах ошибок?

Вообще маппинг между приложениями и БД всегда идет сложным образом. Обычно m : n. И очень редко удается сделать 1:1 или как-то по другому.