Chat Plugin: Performance at Scale - Disabling Retention & Heavy API Use?

I’m exploring an alternative use case for the Discourse Chat plugin and have some questions about its performance limits, specifically concerning data retention and heavy API usage.

To provide some context, we are looking for a threaded commenting system. The “threaded replies” feature within the Chat plugin provides a user experience that is much closer to our needs than the standard topic/post structure. For this reason, we are considering using chat channels as persistent comment threads.

Because of this use case, we would need to keep the chat history indefinitely. This leads to our main concern: performance at a very large scale.

Our projected usage is high:

  • Total Messages: Somewhere between 1 to 10 million messages.

  • Channels: Approximately 150 to 200 channels.

Our primary questions are:

  1. Is it possible to completely disable chat retention or increase it to support mentioned message number? For example, by setting the retention period to 0 or a very large number.

  2. How would API performance be affected? We plan to heavily use the Chat plugin’s APIs to integrate with our external system. Our primary access pattern would be fetching messages in chronological order (newest to oldest) for both main channels and threads. Would this kind of frequent API polling on channels with massive histories create a significant server load?

  3. What would be the general performance impact on the server and database of storing millions of chat messages permanently? Specifically, how would this affect:

    • Server CPU and RAM usage?

    • Overall site responsiveness?

  4. Are there any known “breaking points” or soft limits where the system’s performance starts to degrade significantly under this kind of load?

We understand this is an unconventional use of the chat plugin and that disabling retention is not a best practice. Our goal is to determine the architectural limits of the system—both in the UI and via the API—before committing to this approach.

Any insights from the team or community members who have run chat at a large scale would be incredibly valuable.

4 Likes

Hey @Nima1, I can start to answer some of these questions:

Yes, it’s possible. You can set the chat channel retention days to “0” to retain messages forever — but given the scale of what you’re doing, you’re right to wonder about performance impacts. I’ll also note that we do not currently support searching chat messages (it’s on our minds but is not currently planned). This means that even if you are retaining messages forever, given your high project usage, it may not be feasible for members to find specific messages.

I’m not positive about the answers to these questions, let me check with some of the engineers who have worked on chat the most to see what they think.

I’d also love to learn more about your use case — would you be willing to share some more detail about what you’re working toward?

2 Likes

Hi Lindsey,

Thank you for the response and for checking with the engineering team. I’d be happy to share more about our use case.

We are building a community for cryptocurrency enthusiasts. For each major crypto asset, we want to create a dedicated, persistent channel for real-time discussion.

We found the standard topic/post model isn’t ideal for this because:

  1. Pace & Format: The conversations are rapid and consist of short messages, updates, and reactions, which is a natural fit for the chat format.

  2. Information Flow: Our users need to see the newest messages first and scroll up for recent history, which is the default behavior in chat. In contrast, topics are designed to be read chronologically from oldest to newest.

The chat plugin’s threaded replies and reverse-chronological display are a perfect match for the user experience we want to create.

Our main challenge is scale. Because we’ll have a channel for each asset, we anticipate needing hundreds of channels, each potentially holding a very long history. This is why we’re so interested in the performance limits.

We are committed to using Discourse because of its powerful moderation, user management, and gamification features, which are critical for building a healthy community.

Looking forward to hearing what the engineers think. Thanks again!

Thanks for sharing more about what you’re hoping to do, @Nima1!

After chatting with our team, I’m afraid we can’t speak with certainty about how performance would be impacted by this volume of messages — we don’t have many folks using chat right now at this scale and where you choose to host your site will have a big impact.

Are you intending to self-host Discourse?

1 Like