Scale Mattermost up to 100000 users

import Inc0_lifetime_storage from './lifetime-storage.mdx'; import Inc1_estimated_storage_per_user_per_month from './estimated-storage-per-user-per-month.mdx'; import Inc2_additional_ha_considerations from './additional-ha-considerations.mdx';

<PlanAvailability slug="ent-plus" />

This page describes the Mattermost reference architecture designed for the load of up to 100000 concurrent users. Unsure which reference architecture to use? See the scaling for enterprise documentation for details.

• High Availability: Required
• Database Configuration: writer, multiple readers

<Note>

- Usage of CPU, RAM, and storage space can vary significantly based on user behavior. These hardware recommendations are based on traditional deployments and may grow or shrink depending on how active your users are. - From Mattermost v10.4, Mattermost Enterprise customers can configure Redis (Remote Dictionary Server) as an alternative cache backend. Using Redis can help ensure that Mattermost remains performant and efficient, even under heavy usage. See the Redis cache backend configuration settings documentation for details. - While the following Elasticsearch specifications may be more than sufficient for some use cases, we have not extensively tested configurations with lower resource allocations for this user scale. If cost optimization is a priority, admins may choose to experiment with smaller configurations, but we recommend starting with the tested specifications to ensure system stability and performance. Keep in mind that under-provisioning can lead to degraded user experience and additional troubleshooting effort.

</Note>

Requirements

<style> .scale-requirements-table &#123; width: 100% !important; table-layout: fixed !important; border-collapse: collapse; font-size: 0.9em; overflow-wrap: break-word !important; word-wrap: break-word !important; &#125; .scale-requirements-table th, .scale-requirements-table td &#123; border: 1px solid #ddd; padding: 8px; text-align: left; vertical-align: top; word-wrap: break-word; overflow-wrap: break-word; &#125; .scale-requirements-table th &#123; background-color: #f8f9fa; font-weight: bold; &#125; .scale-requirements-table col:nth-child(1) &#123; width: 25%; &#125; .scale-requirements-table col:nth-child(2) &#123; width: 10%; &#125; .scale-requirements-table col:nth-child(3) &#123; width: 18%; &#125; .scale-requirements-table col:nth-child(4) &#123; width: 23%; &#125; .scale-requirements-table col:nth-child(5) &#123; width: 24%; &#125; </style> <table class="scale-requirements-table"> <colgroup> <col style={{width: '25%'}} /> <col style={{width: '10%'}} /> <col style={{width: '18%'}} /> <col style={{width: '23%'}} /> <col style={{width: '24%'}} /> </colgroup> <thead> <tr> <th>Resource Type</th> <th>Nodes</th> <th>vCPU/Memory (GiB)</th> <th>AWS Instance</th> <th>Azure Instance</th> </tr> </thead> <tbody> <tr> <td>Mattermost Application</td> <td>6</td> <td>16/32</td> <td>c7i.4xlarge</td> <td>F16s v2</td> </tr> <tr> <td>RDS Writer</td> <td>1</td> <td>16/128</td> <td>db.r7g.4xlarge</td> <td>E16as v6</td> </tr> <tr> <td>RDS Reader</td> <td>5</td> <td>16/128</td> <td>db.r7g.4xlarge</td> <td>E16as v6</td> </tr> <tr> <td>Elasticsearch cluster</td> <td>4</td> <td>8/64</td> <td>r6g.2xlarge.search</td> <td>E8ads v6</td> </tr> <tr> <td>Proxy</td> <td>1</td> <td>16/64</td> <td>m7i.4xlarge</td> <td>D16s v6</td> </tr> </tbody> </table>

Lifetime storage

<Inc0_lifetime_storage />

Estimated storage per user, per month

<Inc1_estimated_storage_per_user_per_month />

Example

A 100000-person team with medium usage (with a safety factor of 2x) would require between 10.56TB ¹ and 52.8TB ² of free space per annum.

¹ 100000 users * 5 MB * 12 months * 2x safety factor

² 100000 users * 25 MB * 12 months * 2x safety factor

We strongly recommend that you review storage utilization at least quarterly to ensure adequate free space is available.

Additional considerations

<Inc2_additional_ha_considerations />