[haffla]

Zulip is using Python and Postgresql. Is this a great choice of stack for a chat app? I'd love to know how Zulip performs with hundreds of concurrent users.

I am currently looking into Rocket.Chat which is based on Meteor (NodeJS) and MongoDB, a stack which, for me, seems better suited for this kind of app. But hey, I don't know, I haven't done performance tests or anything.

Does anyone know about any hard limits with either Zulip or Rocket.Chat?

[web007]

We tried RocketChat for about a day before switching to Mattermost. It wasn't great, but worked okay for a team of 20-30.

After a month or so of mumbling and grumbling on MM we went to Zulip, and brought on another dozen or so designers and PMs. Zulip lasted about 6 months before management implemented Slack company-wide and rolled out for the other 100 sales and support teams.

Zulip was the best for engineering, by far, but it was doomed from the start because the UX wasn't as simplified and polished as Slack. It didn't Just Work, you had to think and use it properly to see the benefits.

Back to your question: no limits I know of, and a t2.medium was 90% idle for an active team up to ~50 without a hitch. I think the docs (or launch announcement?) mentioned a large deployment around 1k, but I can't remember the details. You'll definitely want to test your expected configs and hardware to be confident.

[tabbott]

We've been extremely happy with the Python 3 (with mypy static types) and Postgres stack. Like with any app, you need to take some care to design the database model right and avoid database queries in loops. But with our design, all the expensive operations are done in the database and cache, so Python is just as fast as anything else. And because our data model design and indexes are correct and Postgres is awesome, the database queries are all fast. We use Postgres' built-in full-text search, and people frequently praise Zulip's search as being unusually good for finding past conversations.

For Zulip's scalability, see https://zulip.readthedocs.io/en/latest/production/maintain-s...

[rkangel]

PostgreSQL is really really good, for any normal amount of data, or any normal number of users. If you can make Postgre do most of the work, it doesn't hugely matter what you build on it.

If you're Facebook or Google scale, you may need something with a different performance characteristics, but 99.9% of the world doesn't. Except that even Facebook doesn't: as I understand it they still use carefully sharded MySQL.

[haffla]

Yes I guess with the right hardware everything is possible. The question is if you can get away with smaller hardware when using non-relational databases. Well one would have to test this.

[eksmast]

If you care to login, there is a thread on zulip here https://chat.zulip.org/#narrow/stream/2-general/subject/Scal...

regarding scaling.

Relevant info- Zulip is designed for ~15k users with real-world tests of 3k users. Not sure about concurrent users.

[johnx123-up]

Just curious, is there any integration with Restyaboard?

[haffla]

Interesting thread, thanks

[eeZah7Ux]

Python fits very well this use-case. If you design a chat app properly you should be doing very little computation. With Python's async you can scale up to large number of sessions / users / channels without issues.

[jannes]

Are you seriously saying PostgreSQL might not be suited for concurrent workloads?

[haffla]

I said concurrent users as in users that are online at the same time, each of them probably connected via WebSocket streaming and sending messages.... Thanks for the downvote...

Regarding Postgresql, are you denying that relational DBs are less suited for write intensive tasks than say a NoSQL DB like MongoDB is? And couldn't a chat with thousands of users be a more than average write intensive scenario?