Sizing
Applies to: SimpleTwo 0.9.x · Checked: 19.10.2026
Three sizes, and they are not invented for the manual: they are the same S / M / L the product's load profile is measured against.
| S | M | L | |
|---|---|---|---|
| Accounts | 150 | 800 | 4 000 |
| Active at the busy hour (70%) | 105 | 560 | 2 800 |
| Concurrent connections at peak | 150 | 800 | 4 000 |
| Group conversations | 19 | 100 | 500 |
| Direct conversations | 420 | 2 240 | 11 200 |
| Messages after one year | 1.6 M | 8.4 M | 42 M |
| Concurrent call participants | 15 | 70 | 350 |
At the busy hour there are about as many live connections as the organisation has people: 0.7 active × 1.4 devices ≈ 1.0 per person. It is worth stating because it can be checked in production with one command — the messaging service's connection count should match headcount.
1. Hosts to start with (size S)
Every size is for x86-64 (amd64): the server side is built for this architecture only, and ARM hosts are not supported.
| Role | vCPU / RAM / disk | Network | Limited by |
|---|---|---|---|
| coordinator | 2 / 4 / 20 GB | 100 Mbit/s, public IPv4 | nothing |
messaging | 2 / 4 / 100 GB SSD | 100 Mbit/s, public IPv4 | disk, while attachments live on it |
sfu, each | 4 / 8 / 20 GB | 1 Gbit/s, public IPv4 | bandwidth |
turn | 2 / 2 / 20 GB | 1 Gbit/s, public IPv4 | bandwidth |
calendar | 2 / 4 / 20 GB | 100 Mbit/s | polling by external calendar clients |
gateway, each | 1 / 1 / 20 GB | 1 Gbit/s | bandwidth |
postgres | 2 / 4 / 40 GB SSD | private network | disk |
redis | 1 / 1 / 10 GB | private network | nothing |
s3 | 2 / 4 / disk by media | private network | disk |
support | 2 / 4 / 20 GB | private network (DMZ) | memory |
monitoring | 2 / 4 / 40 GB SSD (M — 50 GB, L — 4 / 8 / 80 GB) | private network | disk: logs and traces by ceiling, metrics by age |
For M and L what grows first is media; the messaging service and the database scale later, and mostly by disk.
identity, mail, mx, drive and mcu are left out of the table on purpose: they have not had a load
run yet, and a host size without one is a guess. For mail the disk is what matters, and it can be
worked out in advance: 1.87 GB per person a year, 1.33 GB after attachment dedup — over three
years 0.6 TB for S, 3.1 TB for M and 15.6 TB for L. mx keeps its own queue on disk: it holds
messages until the mail cluster or the recipient's server has taken them; there are two mx nodes by design. mcu is sized by concurrent calls from meeting-room terminals, not by participants; today it
forwards media without transcoding, so it is bound by the network and the port range, not by CPU.
It grows out: every node keeps its own Call cap (by default, what the port range carries) and
hands the rest to a peer; the bench will give the numbers for the caps.
2. The media pool: arithmetic, not intuition
An sfu node is limited by bandwidth, not CPU. The budget per node is 700 Mbit/s of egress
(70% of a gigabit interface), and a conference participant pulls ≈ 2 Mbit/s.
| S | M | L | |
|---|---|---|---|
| Steady-state SFU egress | 30 Mbit/s | 140 Mbit/s | 700 Mbit/s |
| Nodes for steady state | 1 | 1 | 1 — exactly at budget, no headroom |
Share through turn | 9 Mbit/s | 42 Mbit/s | 210 Mbit/s |
But the pool is sized by the all-hands, not by the steady state: a viewer of one presenter with a shared screen pulls ≈ 2.5 Mbit/s.
| All-hands | Participants | Egress | Nodes at budget | Deploy (N+1) |
|---|---|---|---|---|
| S | 150 | 375 Mbit/s | 1 | 2 |
| M | 800 | 2.0 Gbit/s | 3 | 4 |
| L | 4 000 | 10 Gbit/s | 15 | see the caveat below |
For a 4 000-person organisation an all-hands with everybody in it runs into architecture rather than into a hardware budget: that scenario needs a different distribution model, not a bigger pool. The load run for the large size is executed at 500 participants and extrapolated, and the report says so. When planning L, plan either smaller gatherings or a broadcast — not 15 SFU nodes.
N+1 is not belt-and-braces. Losing a node drops the rooms that lived on it: live sessions do not migrate between nodes. An organisation for which calls are a working tool deploys one node more than the arithmetic asks for.
3. Disk for attachments
Counted by media, not by people: ≈ 0.8 GB per person per year, assuming 8 files per working
day at an average of 400 KB. That is ≈ 120 GB/year for S, ≈ 640 GB for M and ≈ 3.2 TB for L —
and it is this column that decides whether you need the s3 role or external storage.
Meeting recordings are counted separately and on top: one conference recording is a file the size of a screen recording, not of a conversation.
4. XL: an organisation of up to 100 000 people
Plainly, first: this size has not been measured. The product's load profile ends at 4 000, and media for that size is already extrapolated from 500 participants. Everything below is arithmetic from the same per-person numbers, and it is useful for exactly one thing — showing what runs out first.
| L (4 000) | XL (100 000) | |
|---|---|---|
| Concurrent connections at peak | 4 000 | ≈ 100 000 |
| Messages per year | 42 M | ≈ 1 billion |
| Attachments per year | 3.2 TB | ≈ 80 TB |
| Concurrent call participants | 350 | ≈ 8 700 |
| Steady-state SFU egress | 700 Mbit/s | ≈ 17 Gbit/s |
sfu nodes for steady state | 1 | ≈ 25 + 1 |
What runs out first
- The all-hands. It does not add up at 4 000 already, and at 100 000 it needs 250 Gbit/s of egress — that is distribution, not a media pool. An organisation this size holds all-hands as a broadcast, and the product has no broadcast yet. When planning XL, plan that separately: it is work, not a setting.
- Messaging sockets. The service scales by replicas: they share Postgres, object storage and the bus, and the bus carries events between them and holds presence globally. But the unit's open-file limit is 65 535, so one replica cannot hold 100 000 connections even in theory. Plan several replicas behind a load balancer, and watch what the bus does: it receives a publish per event and fans it out to every replica.
- Postgres. A billion messages a year means partitioning, a tuned cluster of its own and its
own backup strategy. The bundled
postgresrole is sized for an installation, not for that; XL means an external cluster and a DBA. - Object storage. 80 TB a year is a lifecycle policy and a retention decision, not a bigger disk. This is the scale at which retention stops being a theoretical section.
- Push. Fanning out to 100 000 devices is a question of throughput to APNs and FCM and of their own limits; we have not measured it.
- The directory and the control plane. The coordinator is not in the path of a message or a call, and that is what saves it: its load is sign-in, directory synchronisation for 100 000 accounts and telemetry. But its database is single and on one machine, and for XL that is the first thing to test separately.
What to do with that list
It does not say "impossible". It says XL is a project, not a size on a menu: before promising a customer that scale you need a run against their profile, an answer about broadcast, and a decision about the Postgres cluster. If a tender says 100 000 people, show this page rather than the S table multiplied by 25.
5. What grows and what does not
| Grows with headcount | Barely grows |
|---|---|
| the media pool, bandwidth, attachment storage | the coordinator: it is in the path of neither a message nor a call |
| the database: messages per year | redis: it holds room routing, not data |
| VPN nodes — by location, not by headcount | calendar: load comes from external clients polling, not from headcount |