I'd probably recommend ScyllaDB for NoSQL. It's a replacement for Cassandra (which it's mostly compatible with) which is more or less the de facto standard for large NoSQL deployments at big companies, but it's written in C++ rather than Java so it's even faster (and has more consistent latency) and easier to deploy. And it's been around long enough at this point that it's established and not likely to just disappear.
It's a shame your devs don't like SQL. It's probably my most useful developer skill. Saves so much time elsewhere. Having said that, a messaging app that you really want to scale HUGE (like Discord or Facebook Messenger huge) is one place where the NoSQL solutions are justified.
I'd suggest you and your team shouldn't rule out SQL-like databases, given a lot of very competent NoSQL databases have SQL-like syntaxes (say Cassandra or ScyllaDB, what Discord went with). And regarding hiding it behind an ORM, if you want or need cream of the crop performance not only do you need to have chosen a database that fits your needs, but you will also need to occasionally work very close to the database to avoid abstraction inversion situations.
“Best” depends on your use case. I don’t even think a SQL database is an option for a chat app since it’s write heavy. FB Messenger uses HBase and Discord uses Cassandra and they’ve done their research at scale, so those could be possible options.
Which self hosting instance would go at the size of Facebook or Discord?
Just because Discord took a method doesn't mean a competing product should too.
People opting to use a meme "database" instead of a real DBMS is kind of a large red flag to me. I am hard pressed to imagine data more relational than chat messages and user accounts.
I refuse to believe this is due to technical reasons, as long as we are talking ACID compliant data storage. A well configured PostgreSQL will blow MongoDB out of the water while actually caring about your data.