Вполне себе любая развитая современная РСУБД годится для этой задачи.
MySQL, PostgreSQL...
А по мере роста нагрузки - тут не выбором СУБД нужно заморачиваться, а MQ-сервер ставить. Он гораздо легче сравиться с бешенными нагрузками.
Как вариант - Queue на базе Tarantool, например. Я даже не знаю что вы там должны такое сделать, чтобы заткнуть его производительность. При условии того, что на сервере достаточно много оперативной памяти.
Из самого критично подозрительного - полнотекстовый поиск.
Впрочем, полагаю, что полнотекстового поиска средствами MySQL или PostgreSQL вплоне хватит.
Если уж делать прям таки серьезный чат типа Slack, то для полнотекстового поиска я бы вообще отдельную специализированную БД держал бы. Например, SphinxSearch.
Но, для начала, возможностей PostgreSQL или MySQL будет вполне достаточно.
Что до Mongo... Если вам не нужна репликация без консистентности. Зато быстрая...
Так вот если вам не нужна такая репликация, то Монга вам не нужна.
РСУБД будут существенно быстрее.
Вот ежели вы планируете заводить ваш чат в кластер, когда одного сервера вам не хватит, то тут да, тут РСУБД не лучший выбор. Тут бы я рекомендовал как раз Монгу.
Но опять таки кластер серверов для чата вы без MQ не сделайте.
Вывод:
Начните с обычной РСУБД.
Как начнутся затыки - рассмотрите MQ
Как начнется рост до масштаба планеты - рассматрите Монгу.
Вся система работает с бд MySQL - InnoDB, сообщения пишутся в бд при каждой отправке (INSERT), пока сервис еще не запущен, сообщений мало (только мои тестовые) все работает шустро, но вот когда запущу и количество сообщений перевалит за несколько миллионов, что будет тогда с моей бд? Начнутся жесткие тормоза при select и insert?
Вам никто не мешает это проверить.
Сгенерируйте миллион случайных сообщений.
При грамотном использовании индексов - ровным счетом никаких проблем ни на миллионах ни на миллиардах записей.
Средний
