а так в целом на PG/MySQL + Redis можно довольно долго масштабироваться (не факт конечно что самый бюджетный вариант) особенно если пока непонятны до конца паттерны доступа. в PG можно и NoSQL-way использовать, масштабирование записи наверно самая большая проблема в этом случае.

Поддерживаю, 10к это немного а если сделать умно кеш redis/in-memory/cdn/browser с max age / etag так вообще ниочом

Нужно понимать бизнес логику запросов, голые цифры ни о чем не говорят

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

Да, забыл упомянуть. Это мульти-юзер чаты. Все сообщения будут привязаны к айди чата и сортироваться будут по времени получения на сервере. В общем-то как и в любом другом чате. Отличие будет в том, что у нас ещё дополнительные поля, по которым будет фильтр, и которые должны будут попадать в различные индексы для поиска. Например, тип сообщения. Ну и таких 4-6, а может и больше полей.

Это все звучит как тз для архитекта, шабашки берут от 200 баксов в час, и сделают вам архитектуру пож любые функциональные и не функциональные требования

По лэтенси не критично, но до секунды это нормально. 10к в контексте чатов - это только новые сообщения (вставки).

Да собственно это мы уже сами оформили в таком виде. Как и писал выше, уже рассматриваем различные варианты.

Из того, что уже наинвестигали - постгрес на Авроре либо РДС упирается в 40к транзакций в секунду. Что в принципе в нашем случае достаточно, но хотелось бы побольше 9апас иметь. Естественно, что Аврора в таких масштабах будет подешевле, потому что может скейлиться вниз (если смотреть серверлесс). Динамо по умолчанию тоже 40к лимит на wcu, но можно увеличить. Но так как все паттерны пока ещё не ясны, то будет не гибко ее использовать. Плюс каждый паттерн - это отдельный глобал индекс, что увеличивает стоимость в разы.
Остаётся монга и Кассандра, которые надо менеджить самостоятельно.
Документ-дб отпал, из-за проблем совместимости.
По подозрению в той же проблеме пока не рассматриваем кейспейсы.

Может осталось что-то ещё из сервисов, которые стоит также рассмотреть? Или может мы где-то ошиблись в своих предпочтениях?

я ненастоящий сварщик (в смысле не архитектор AWS), но у нас юзерская статистика (клики по UI) складывается в redshift (я тут ваш кейз не очень понял, поэтому не могу сказать, надо ли вообще думать о редшифте), а данные кроулера доменов в монгу, с монгой особо проблем не имеем в плане мейнтенанса, с редшифтом понятно что вообще никаких проблем.

Редшифт очень не любит много мелких запросов, это аналитическая дБ.

да, согласен.  иногда это даже бесит 🙂  идёшь руками поглядеть что-то простое, а ждёшь столько же времени, сколько выполняется что-то сложное.  у нас как раз для аналитики оно.

Ну вот если ему вжарить 10 запросов в секунду оно встанет раком из-за перегруза планировщика

Редшифт - да, не рассматриваем, так как это аналитика, а нам нужна так сказать операционка.
В любом случае, всем спасибо за ответы и комментарии. Будем выбирать из того, что уже имеем.

Посмотрите ещё Нептун, он как раз под логику графов создан

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

Вот чат и есть граф

А потом у вас треды в чате появятся

спасибо! рассмотрим, хотя мне кажется, что чат это слишком простой граф, чтобы привязывать графовую базу.

Если 10 к на чтение ,то выдержит любая  база. Если это на запись , то реляционка потянет только на ssd, если вы планируете делать commit после каждой вставки .т.е это скорее будет предел для Авроры,postgre,mysql И в дальнейшем вам нужно будет делать шардирование и разносить чаты по разным инстансам. Т.е у вас будет много инстансов mysql, например и вы будите в приложении или где -то ещё делать роутинг на нужный инсианс. Ну или взять диманодб.