MQTT Performance Tests: Message Persistence

Persistent Point-to-Point: Durable Delivery

This test repeats one-to-one delivery with persistent sessions, each broker with the persistence it offers, so queued messages can survive a broker restart. The measured rate and latency show the cost of that durability; what a failure can still lose depends on the broker and its configuration - for XMQ see Persistence.

The scenario is point-to-point, the same shape as the in-memory point-to-point page: each publisher has its own subscriber on its own topic, so the broker does no fan-out and what is measured is the per-message cost of routing plus the cost of persisting it. Both client groups connect with clean_session off, so a run at 60K holds 120,000 persistent sessions. Each publisher sends one message per second with a 16-byte payload, and every broker starts against empty storage.

This configuration answers a particular need, and is not the one most deployments want. Persistence earns its cost where a message that never arrives is worse than a message that arrives late: commands to equipment that is intermittently connected, orders and transactions, anything a subscriber must receive even if it was offline when the message was sent, or if the broker restarted between the two. For live telemetry, metrics and status streams — where the next reading supersedes the last and a gap costs nothing — persistence buys nothing, and the in-memory figures on the other test pages are the ones that apply.

It is worth setting the numbers below against that. Workloads that genuinely need durable delivery are usually counted in messages per device per minute rather than per second, so the rates measured here are well clear of what they ask for. The ceiling matters when durable and high-volume traffic share one broker, and the two can be separated: only sessions connecting with clean_session off and messages sent at QoS 1 or above pay for persistence at all, so a broker can carry both without the fast traffic paying the durable traffic's cost.

The brokers do not persist the same thing, and that is part of the result.This historical XMQ run used Redis AOF with appendfsync everysec andmax_queued_writes 1000. It used asynchronous write-behind and is closest to today's Persistent mode, but differs because current Persistent mode disables AOF. It is not a measurement of today's Durable mode, which uses appendfsync always and waits for local AOF fsync before successful acknowledgements. HiveMQ uses its file persistence; both store each message. EMQX stores messages with durable sessions enabled. FlashMQ saves its sessions to disk periodically and at shutdown, and Mosquitto saves a snapshot of its in-memory database on an interval — so a crash loses what arrived since the last save, and their figures are those of in-memory delivery. Each broker's settings are recorded with its results.

XMQ 1.0.2 and FlashMQ 1.27.2 were re-measured on 2 November 2026 on the same c5n.4xlarge host (16 vCPU, 40 GB) as the other brokers here. Percentiles are shown where the run recorded them; a dash means its result file has no percentile section.