У вас здесь 2 вопроса:
1) какую СУБД использовать, это полностью зависит от данных и как к ним планируется обращаться.
2) вы прям сразу хотите запилить шардирование, это вполне возможно на любой СУБД.
В шардировании основная проблема это когда нужно получить данные из многих шардов. Сперва проблема выбрать критерий шардирования, вы вроде бы его выбрали и у вас все легко делится по пользователям. Но остается момент формирования статистики и аналитики: вам нужно будет обращаться ко всем шардам, забирать из них данные и делать map-reduce. Очевидно, что ваше ПО должно позволять параллельно формировать запросы и обрабатывать их. А вот, миграции - это не проблема, наоборот чем меньше шарды, тем проще их делать.
Разумеется, у вас должна быть отлаженная полностью автоматизированная система деплоя, которая позволит накатывать те же миграции параллельно на множество шардов. Вам нужно будет создать систему map-reduce, а здесь уже интереснее, если вы будете оперировать малым кол-вом данных, то нет проблем, в противном случае вам придется подымать отдельную аналитическую СУБД и загружать в нее данные. Таскать по сети миллионы строк между разными машинами будет не весело.
И еще момент, не обязательно создавать на каждого пользователя отдельный шард, вы можете объединять их по какой-либо формуле, тогда не обязательно заводить миллионы шардов. Либо все же сделать миллионы шардов, но располгать скажем на 1 машине 1000 шардов, и вы сможете если понадобится изменять эту цифру.
Как все делают когда не умещаются данные на одном сервере? Применяют горизонтальное масштабирование.
Что если запросов очень много? Добавляют балансировщик.
А что если данных в БД полно? Делают репликацию. И вот тут вопрос.
Нет проблем уместить много данных на одном сервере (есть, конечно, BigData но это совсем про другое), проблема в том что при увеличении кол-ва данных в БД начинается деградация производительности СУБД, и примерно к 1млрд строк она проседает очень сильно (если кончено у вас строка это не 5 integer, а скорость ответа вы считаете в миллисекундах, а не в секундах). И в этом случае мы делим данные на разные СУБД, т.е. шардируемся.
Если очень много запросов чтение, то нет проблем поставить нужное кол-во слейвов и делить нагрузку между ними, т.е. реплицировать master.
Ну и, шардирование не такая простая вещь как кажется. Не стоит прям на старте ее впиливать, а вот подготовить данные для возможного деления на шарды стоит.
Средний
