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: 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. 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? 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? 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.

Hey @Nima1, I can start to answer some of these questions: [image] Nima1: 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. 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. [image] Nima1: How would API performance be affected? [image] Nima1: What would be the general performance impact [image] Nima1: Are there any known “breaking points” or soft limits where the system’s performance starts to degrade significantly under this kind of load? 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?

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: Pace & Format: The conversations are rapid and consist of short messages, updates, and reactions, which is a natural fit for the chat format. 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?

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

Product Support

Nima1 (Nima) August 7, 2025, 7:29am 10

Hi, thanks for the quick reply and for checking with the team!

To answer your question: yes, we are self-hosting. I have already set up the instance.

Topic		Replies	Views
Scaling Discourse Chat for High Channel Volume: Limitations, REST API & Best Practices? Product Support chat	0	106	March 29, 2025
Discourse Chat is now available. Try it out today! Blog chat	4	2648	August 20, 2022
Chat history backup/archive functions Product Support chat	6	1092	September 10, 2023
Retention settings per chat channel Feature chat	6	1096	March 4, 2024
Introducing Discourse Chat (BETA) Announcements chat , new-feature	142	29384	August 3, 2022

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

Related topics