Just to clarify for anyone here reading, Zulip can be scaled out, but largely our philosophy is that you should only scale out if you need to, since it comes with extra fiddly operational headaches and is expensive in dollars. We've designed Zulip with an efficient data model and well-indexes queries, and are constantly working as we add new features to maintain the property that only multi-tenant installations like Zulip Cloud should need to scale it out.

In particular, Zulip on a single server with 16GB of RAM can handle 10,000s of users, thousands of which are concurrently active. (That's what we use for chat.zulip.org, for example, and the machine is usually about 96% idle with only half its memory used).

(Keep in mind that Zulip's public access option means you don't need every user to create an account in order to access content).

I don't know your context, so I can't comment on whether zulip would be suitable. But there are very few communities today having complex conversations involving 100K+ people in a single organization/workspace, so I would expect it to be quite rare that autoscaling would be relevant. (Certainly there are Discords with over a million users, like the Midjourney one, but most of those users are just users the product, not having discussions at all; the company famously made the unusual decision to only offer a Discord bot as UI for their product).

https://zulip.readthedocs.io/en/latest/production/requiremen... has some basic guidelines on Zulip's scalability for a single-instance deployment, but those are fairly conservative -- the goal is for folks to be able to deploy with those settings and be safe even if their load profile per user is fairly heavy for whatever reason.