Skip to content

Synapse Pro for small hosts (multi-tenancy)

Synapse Pro for small hosts is a multi-tenancy feature which enables hosting multiple small Synapse homeservers in a single Python process, dramatically reducing resource overhead and cost.

Ideal for hosting providers and use cases like TI-Messenger wanting to run many small homeservers efficiently.

Project-specific terminology:

  • shard: A single instance of the multi_synapse shard process, which can host multiple Synapse homeserver tenants.
  • tenant: A single Synapse homeserver instance hosted by a shard, with its own configuration and database. You might also think of this as a "virtual host".

Note: Synapse Pro for small hosts is not compatible with Synapse Workers. If you need to use workers, the homeserver is probably not something that we'd call a "small host" anyway and is better served by the standard dedicated Synapse Pro deployment for large hosts.

Configuration

See configuration documentation for details on how to configure Synapse Pro for small hosts.

Deployment recommendations

When deploying on Kubernetes (k8s), we generally recommend using fewer larger nodes rather than many smaller nodes. This approach offers several advantages:

  1. Resource Efficiency: Larger nodes can be more heavily oversubscribed when running workloads with low average utilization.
  2. Reduced Overhead: Each k8s node carries approximately 1Gi memory and 0.2 CPU cores of overhead for monitoring and instrumentation. Fewer nodes mean less aggregate overhead.
  3. Cost Considerations:
    • For many cloud providers (including AWS EC2), the cost differences between node sizes are often marginal when comparing equivalent total compute capacity (e.g., 6 xlarge nodes vs. 3 2xlarge nodes may have similar total costs).
    • The "one node per host" approach typically becomes expensive quickly due to the per-node overhead.

Note that these recommendations may vary based on your specific workload characteristics and cloud provider pricing structures. Always perform cost/performance analysis for your particular use case.

How many shards per server node?

Practically, this equates to preferring bigger machines and running one multi_synapse shard per CPU core available on the node.

How many tenants per shard?

The number of tenants per shard is highly dependent on your usage patterns but we're CPU limited as Python can only use up to a single CPU core. In practice, this means a shard might host a few very active tenants or many less active ones.

Using one of our standard usage patterns (message sending1), we've found that total event persistence rate is the primary contributing factor to CPU usage. Below is a small table of examples:

Since these are "small hosts", let's assume that each homeserver tenant has 5 users. The key metric, however, isn't the user count but the total event persistence rate for all tenants on the shard.

To explain the first row of the table, if we expect a message per user every 107s on average which equates to 2.34 Hz of message sending and 10 Hz of event persistence across all homeservers; a single shard can support 250 total users spread across 50 homeserver tenants.

Number of tenants Total number of users (5 users per-tenant) Average message send time per-user Total event send rate Total event persistence rate1 CPU Usage (measured2)
50 250 107s 2.34 Hz 10 Hz 75%
40 200 85s 2.35 Hz 10 Hz 75%
30 150 62s 2.42 Hz 10 Hz 75%
20 100 40s 2.50 Hz 10 Hz 75%
10 50 18s 2.78 Hz 10 Hz 75%
5 25 7s 3.50 Hz 10 Hz 75%

It's best not to run at the ragged edge of CPU usage so we also recommend a 25% headroom buffer. Running at 100% of a CPU core results in bad Twisted reactor tick times in Synapse which equates to long event send times, etc. The 25% headroom figure is a bit arbitrary but is based on our load testing where we've found pushing it further can result in degraded performance.

To find your current event persistence rate in order to evaluate whether Synapse Pro for small hosts could work for you, see the purple dots representing "All events being persisted" in the "Event Send Time Quantiles" graph from the standard Synapse Grafana dashboard.

Grafana dashboard showing off a shard with 50 homeserver tenants under a load test. Sub-200ms event send time, ~10 Hz events being persisted, stable CPU usage around 75%, and low memory usage.

How much memory per server node?

Guidance to be determined. A future update will include a heuristic for necessary memory, taking into account Synapse caches and other factors.

  1. Message sending usage pattern: This is as tested by our load test. Every user is sending messages in public rooms and encrypted DMs over federation. Average event send times are sub-200ms (measured). ↩↩

  2. Extrapolated from our 25 - 50 homeserver tenant load tests on a single shard hosted on a c7a AWS instance ("Up to 3.7 GHz 4th generation AMD EPYC processors (AMD EPYC 9R14)"). ↩