Matrix Synapse hardware requirements: a practical resource baseline
For Matrix Synapse with 10 users, 2 vCPU, 4 GB RAM, 60 GB NVMe, and a 1 Gbps port are sufficient, but active federation with large servers requires additional CPU, memory, and disk capacity from day one.
Matrix Synapse hardware requirements cannot be calculated from the number of registered accounts alone. Synapse serves local rooms, stores message history, PostgreSQL indexes and media files, and continuously syncs with remote homeservers. A server for 20 employees in one private room may run on 2 vCPU, while an instance with the same 20 users in public federated rooms can require several times more IOPS and bandwidth.
For a typical business or small community deployment, a VPS with 4 vCPU, 8 GB RAM, and at least 100 GB NVMe is a sensible starting point. This configuration can support up to 50 local users, several dozen rooms, and moderate federation without persistent sync delays.
The general approach to infrastructure selection is covered in our guide on choosing hardware for self-hosted applications based on workload: first assess the data operation profile, then reserve CPU, RAM, disk, and network capacity. For Synapse, PostgreSQL performance and NVMe latency matter more than the nominal core count alone.
What contributes to Synapse load
At least three components usually run on one server: Synapse itself, PostgreSQL, and a reverse proxy such as Nginx, Caddy, or Traefik. Redis, Synapse worker processes, Coturn for calls, Prometheus, Grafana, and backup jobs may also consume resources. If everything runs on one VPS, reserve at least 1 GB of total memory for the Linux page cache and system processes.
Synapse uses PostgreSQL more intensively than many common web applications. Every message creates events, event relationships, room state records, index updates, and client sync data. As a result, a slow SATA drive or overloaded shared storage often causes problems before CPU capacity becomes the bottleneck.
Minimum practical configuration
- Test server: 2 vCPU, 4 GB RAM, 40–60 GB NVMe, without open public federation.
- Small team: 2–4 vCPU, 4–8 GB RAM, 80–100 GB NVMe, PostgreSQL on the same host.
- Public community: from 4 vCPU, 8 GB RAM, 150 GB NVMe, database monitoring and at least 30% free disk space.
- Server with calls: a separate Coturn instance and UDP port; call media traffic should not pass through Synapse like a normal HTTP API.
What determines Matrix Synapse server requirements?
Matrix Synapse server requirements are determined by active sessions, room count, history volume, and the federation graph—not just the number of users in the database. An account that has not connected for months creates almost no load; a user running Element Desktop, Element Mobile, and several devices at once generates more sync requests and notifications.
Rooms and state events matter more than account count
Every Matrix room has state: members, permissions, avatars, pinned events, encryption, topics, and other state events. The more members a room has and the more complex its history is, the heavier state calculation and new-device synchronization become. A public room with 2 000 members can create noticeable database load even if only 5 users are local.
Rooms with frequent membership changes, bots, bridges to Telegram, Discord, or IRC, and large Spaces are especially resource-intensive. A bridge can send hundreds of events per hour and expand the database much faster than normal messaging. Disabling federation solely to save resources is not always necessary, but it is worth restricting unwanted room aliases, registration, and media uploads.
Client synchronization and end-to-end encryption
Clients use the /_matrix/client/v3/sync endpoint, often holding a long-poll connection for up to 30 seconds. With 50 active users, the server may handle 50–150 concurrent connections across multiple devices. This does not require hundreds of cores, but it increases load on Python processes, PostgreSQL, and the reverse proxy.
End-to-end encryption is mostly performed on the client, but Synapse stores keys, device list updates, and to-device events. A large number of devices per user increases the volume of sync data. For an organization server, it is useful to limit the number of sessions, monitor inactive devices, and keep Synapse reasonably up to date with current releases.
Looking for a reliable server for your projects?
VPS plans from $10/month and dedicated servers from $9/month with NVMe, DDoS protection, and 24/7 support.
View plans →Scale-to-spec guide: Synapse homeserver RAM, CPU, and pricing
Synapse homeserver RAM CPU resources should include headroom for the PostgreSQL cache: for 50 active users and moderate federation, the practical minimum is 4 vCPU, 8 GB RAM, and 100 GB NVMe.
For 50 active users with moderate federation, 4 vCPU, 8 GB RAM, 100 GB NVMe, and 2 TB of monthly bandwidth are sufficient.
| Load scale | vCPU | RAM | Disk | Network port and bandwidth | Price, $/month |
|---|---|---|---|---|---|
| 10 users, up to 10 rooms, private server | 2 vCPU | 4 GB | 60 GB NVMe | 1 Gbps, from 500 GB/month | approximately from $10 |
| 50 users, 30–100 rooms, moderate federation | 4 vCPU | 8 GB | 100 GB NVMe | 1 Gbps, from 2 TB/month | approximately from $24 |
| 200 users, 100–500 rooms, active federation | 8 vCPU | 16 GB | 250 GB NVMe | 1 Gbps, from 5 TB/month | approximately from $55 |
| 200+ users, bridges, bots, large rooms | 8–12 vCPU | 24–32 GB | 500 GB NVMe | 1–10 Gbps, from 10 TB/month | approximately from $90 |
Prices are general market estimates as of March 2025 for NVMe VPS plans and are not an offer from any specific third-party provider. When choosing a Valebyte configuration, check available NVMe capacity, bandwidth limits, data center location, and whether RAM or disk can be upgraded quickly without a lengthy migration.
How to interpret this sizing estimate
These values apply to Synapse with PostgreSQL on the same server and normal Element client usage. They do not include heavy media storage, mass video uploads, dozens of bridges, or a dedicated TURN cluster. If users regularly share 1–5 GB archives in rooms, disk capacity and monthly bandwidth must be calculated separately.
CPU matters for request handling, federation, JSON serialization, and background tasks, but strong single-core performance is often more important than a large number of slow vCPUs. For 4 vCPU, modern cores clocked from 2.5 GHz are desirable, while PostgreSQL needs stable IOPS without aggressive throttling.
How much RAM does Matrix Synapse and PostgreSQL need?
For the question how much RAM does Matrix Synapse need, the practical answer is: 4 GB is suitable for 10 users, 8 GB for 50, and 16 GB is needed for 200 users or active federation. Of this amount, Synapse typically uses 1–4 GB depending on the number of worker processes; the rest is needed by PostgreSQL and the Linux file cache.
How to allocate memory on one VPS
On a server with 8 GB RAM, do not allocate all memory to PostgreSQL through shared_buffers. A practical starting point is 2 GB shared buffers, a 512 MB–1 GB effective cache estimate in application settings, and at least 2 GB available to the Linux kernel for page cache, Synapse, Nginx, and short-term spikes. Tune exact values using your own statistics rather than copying another configuration.
# /etc/postgresql/16/main/postgresql.conf
shared_buffers = 2GB
effective_cache_size = 5GB
work_mem = 16MB
maintenance_work_mem = 512MB
max_connections = 100
checkpoint_completion_target = 0.9
random_page_cost = 1.1The work_mem value should not be increased without calculation: it applies to sort and join operations rather than acting as a hard total limit. With 100 connections, an excessively high value can lead to OOM. For a small Synapse installation, start with 16 MB and analyze slow queries.
Signs that the server is low on memory
- the
postgresorsynapseprocess is terminated with an OOM Killer message; /syncresponse time rises from hundreds of milliseconds to several seconds;- swap is constantly in use while CPU utilization remains below 50%;
- PostgreSQL repeatedly reads the same pages from NVMe instead of the RAM cache;
- the server becomes unavailable after starting a backup, VACUUM, or Synapse update.
1–2 GB of swap is acceptable as emergency protection, but sustained swap I/O means the server lacks RAM. In this situation, increasing memory from 4 to 8 GB is usually more useful than adding another 2 vCPU.
Matrix Synapse federation server sizing: network, queues, and media
Matrix Synapse federation server sizing starts with evaluating remote rooms: federation with large homeservers can create more load than 200 local users. Synapse receives events, sends PDUs, requests missing events, verifies signatures, and handles key requests, so an unstable network quickly builds up queues.
How much bandwidth does federation use?
Text messages usually use little space: 1 000 short messages can fit into tens of megabytes including JSON and protocol overhead. However, room history, images, voice messages, files, and repeated downloads change the picture. For 50 users with normal business messaging, 2 TB per month is sufficient, while a public server with media and external rooms may use 5–10 TB or more.
A 1 Gbps port is sufficient for almost all deployments with 10–200 users. Route stability, low packet loss, and no strict connection-count limits are more important. For a TURN server, account for UDP separately: one HD call can use hundreds of Kbit/s or several Mbit/s depending on the codec, participants, and network conditions.
How to limit unnecessary federation load
Do not enable open registration without captcha, limits, and an anti-spam policy. For a small organization server, use closed registration, email verification, moderation bots, and public-room controls. Unused bridges should also be removed promptly: every bridge adds synchronization, events, and PostgreSQL records.
# Проверка очередей и состояния Synapse через systemd
systemctl status matrix-synapse
journalctl -u matrix-synapse -p warning --since "1 hour ago"
# Проверка сетевой активности и свободного места
ss -s
df -h
iostat -xz 1If awaiting full state sync, federation retry errors, or slow transactions occur regularly, first check DNS, TLS, MTU, packet loss, and latency to major servers. Adding RAM will not fix a network problem, and starting extra worker processes without diagnosis can sometimes increase pressure on PostgreSQL.
When to move PostgreSQL to a separate server
PostgreSQL should be separated from Synapse when, on a server with 8–16 GB RAM, the database consistently consumes IOPS, query latency rises, and Synapse CPU and database workloads compete for resources. For 10–50 users this is usually unnecessary, but for 200 users, bridges, and active federation, a separate database simplifies scaling and maintenance.
Practical triggers for separating roles
The decision is justified when several signs appear at once: p95 SQL latency exceeds 50–100 ms during peak load, disk utilization stays above 70% for extended periods, VACUUM interferes with sync requests, backups create noticeable pauses, and database growth reaches tens of gigabytes per quarter. A separate PostgreSQL server is also useful for replication and independent NVMe expansion.
Synapse and PostgreSQL need a private low-latency network, ideally below 1 ms within the same data center. Hosting the database on a remote server over the public internet is not recommended: the latency of every SQL query adds up, while channel security and availability become more complex.
Architecture for 200 users
A practical setup is Synapse on 4–8 vCPU and 8–12 GB RAM, PostgreSQL on 4–8 vCPU and 12–16 GB RAM with 250 GB NVMe, a reverse proxy at the frontend, and a separate Coturn instance when calls are needed. If the media repository exceeds 100 GB, it can be moved to S3-compatible object storage or placed on a separate disk.
PostgreSQL backups should be logical or physical and verified through restoration testing. For backup storage and verification, the principles in our article on Proxmox Backup Server requirements and deduplication are useful: a backup without a test restore does not prove recoverability.
Synapse setup: workers, disk, and monitoring
After meeting the basic matrix synapse hardware requirements, performance depends on worker process configuration, PostgreSQL maintenance, and observability. Up to 50 users, one Synapse process is usually sufficient, and workers should be introduced only after measuring actual load.
When do you need workers?
On 4 vCPU and 8 GB RAM, one Synapse process often runs more reliably than a simple setup with multiple workers because every worker adds PostgreSQL connections and consumes memory. Horizontal separation makes sense with hundreds of active sync connections, high CPU load, or a significant federation queue. Before enabling workers, configure the reverse proxy, Redis, and PostgreSQL connection limits.
Prometheus metrics are useful for diagnostics: request duration, active process count, database size, federation rate, event persistence latency, and free disk space. An alert at 80% disk usage is essential: if the volume fills up, PostgreSQL can stop unexpectedly, and recovery may take hours.
Disk capacity, cleanup, and database growth
Do not size disk capacity too tightly. A 70 GB database needs a volume of at least 120–150 GB because VACUUM, indexes, temporary files, updates, and backups require free space. Media files usually grow faster than events: enable upload limits, configure retention for unnecessary files, and monitor the media store directory separately.
The command below shows which directories use space, while the PostgreSQL query helps identify the largest tables. Run heavy maintenance operations during periods of low activity.
sudo du -xh /var/lib/matrix-synapse | sort -h | tail -20
sudo -u postgres psql synapse -c "
SELECT relname,
pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 15;"If the VPS also runs other services such as Git, Nextcloud, monitoring, or CI, Synapse resources cannot be calculated in isolation. For a comparison of CPU sizing approaches, see our article on how workload scale affects server CPU requirements: connection count alone cannot replace measuring actual operations.
Frequently Asked Questions
Synapse resource and scaling answers
How many users can Synapse support on 4 vCPU and 8 GB RAM?
With an NVMe disk and PostgreSQL on the same VPS, 4 vCPU and 8 GB RAM are usually enough for 30–50 active local users, 30–100 rooms, and moderate federation. If members join large public rooms, use bridges, or upload media frequently, the practical limit may be reached earlier. Monitor PostgreSQL latency and free disk space.
Do I need SSD or is NVMe required for Matrix Synapse?
A standard SSD can work for a test server with 10 users, but NVMe is recommended for production. PostgreSQL performs many small random read and write operations, and low NVMe latency noticeably improves sync and federation. For a 50-user installation, allocate at least 100 GB NVMe and retain 30% free space.
When should Synapse be split into workers?
Workers are usually not needed for up to 50 active users. Consider them with 200 or more active users, a large number of concurrent sync connections, or high load on a single Synapse process. Before scaling, add Redis, configure the reverse proxy, and ensure PostgreSQL has 8–16 GB RAM and enough connections.
How much space does a Matrix Synapse database use?
For a small team, message history and service tables may use 10–30 GB, but size grows quickly because of large rooms, bridges, and media. For a server with a projected 50 GB database, allocate at least 100–150 GB NVMe. Account for media files separately: several 1 GB archives change sizing more than thousands of text messages.
Conclusion
Recommended starting configuration
For Matrix Synapse with 10 users, choose 2 vCPU, 4 GB RAM, and 60 GB NVMe; for 50 users with federation, choose 4 vCPU, 8 GB RAM, and 100 GB NVMe. With 200 users, bridges, or large rooms, move to 8 vCPU, 16 GB RAM, and 250 GB NVMe, and separate PostgreSQL when SQL latency rises or IOPS become constrained.
NVMe VPS activated in 60 seconds: full root access, 20+ locations, and card or crypto payments.
Choose a plan
