Eh, I’d honestly just use PostgreSQL for all that, it even has very advanced searching abilities that can out do elasticsearch in many cases, all while using the same database so no worry about things getting out of sync. Plus a chat app is mostly write and read with little to no ‘updating’, which is the perfect use-case for PostgreSQL (it flies the less ‘updating’ you do, mostly just reading and writing).

In general : Do Not Use Cassandra except if you have a really really good team of devs or a really really good team of Operators/SRE. And i would probably put a and here instead of a or if i could.

Cassandra seems nice from the outside, but it is really hard to operate and really hard to develop for, especially if you care about not losing data or getting acceptable time frame for answers.

I feel this is a rare problem to have and once you do have it, you’ll have the resources to address it.

I’d tend to agree with this assessment.

Plus, you also need to think about how the data is related before you think about scaling strategies. With a Chat app every message in the system is basically grouped by “room”. Whether that room accounts for 2 people or a group of people depends on your interface.

When it comes to scaling it, this is a data structure that is very, very easy to shard because you can shard by “room”. All that’s required to make it work is to have a central point to act as a directory of which rooms is on which database and then you can query conversation from there.

What I’m getting at is just, don’t dive to deep into trying to find some ultimate database that can spread itself across hundreds of machines when your data naturally separates into manageable chunks. Those “spreading” solutions become necessary when the data doesn’t separate so easily.

Then probably genserver + postgres will work fine.