Product · Benchmark
How much one MaestroHub server takes in, with nothing lost.
Measured on 19 October 2026 with MaestroHub 3.0, Tier 1: Context Engine with its embedded MQTT broker and embedded time-series database, on one machine. Three machine sizes, every value stored and read back.
At a glance
Guaranteed rates, held for ten minutes. 19 October 2026, MaestroHub 3.0, Google Cloud C3.
29,814values per second, every one stored
Maximum 49,665 per second. Limit: the processor.
74,906values per second, every one stored
Maximum 89,895 per second. Limit: the processor.
164,242values per second, every one stored
Maximum 199,248 per second. Limit: the processor.
Measured 2026-10-19 on Google Cloud c3-highcpu-4, c3-highcpu-8, c3-highcpu-22; MaestroHub 3.0, Tier 1. The published Tier 1 hardware specification (8 vCPU, 16 GB RAM, 200 GB SSD) is the middle machine.
01 What we count
A value counts only when it is safe.
This is not a broker figure. A value counts only after it has passed all four steps below, and at the end of every run we read values back from the historian and compare them with what the devices were told was received.
- AuthorizedThe sender is allowed to write that topic.
- Schema-checkedThe value matches the type its topic declares.
- StoredIt is written to the historian on disk.
- Published liveIt is on the Unified Namespace for every subscriber.
1,000 MQTT 5 devices with 10 numeric tags each. One value per message, QoS 1, so every single value is acknowledged. No batching.
After each run we read 40 tags spread across the devices back from the historian. Every value a device had been acknowledged for was there, in every ingest run.
02 Results per machine
Guaranteed is what we promise to plan with. Maximum is the most the machine stored in full, past the rule.
Swipe sideways to see every column
| Machine | Guaranteed | At the guaranteed rate | Maximum | Limit |
|---|---|---|---|---|
| 4 vCPU2 physical cores · c3-highcpu-4 · memory capped at 4 GB | 29,814 values/s | p99 40 ms from publish to stored2.8 of 4 vCPU busy · 0.65 GB memory | 49,665 values/sheld for ten minutes | Processor |
| 8 vCPU4 physical cores · c3-highcpu-8 · memory capped at 8 GB | 74,906 values/s | p99 35 ms from publish to stored6.3 of 8 vCPU busy · 0.74 GB memory | 89,895 values/sheld for ten minutes | Processor |
| 22 vCPU11 physical cores · c3-highcpu-22 · memory capped at 16 GB | 164,242 values/s | p99 19 ms from publish to stored14.7 of 22 vCPU busy · 0.83 GB memory | 199,248 values/sheld for ten minutes | Processor |
The guaranteed rule, held for ten minutes: every value stored, 99 of 100 values stored within 100 ms of being published, processor below 80%, memory flat. Measured 2026-10-19, MaestroHub 3.0, Tier 1.
Values stored per second (up) against the values per second the devices tried to send (across)
4 vCPU 2 physical cores · c3-highcpu-4
8 vCPU 4 physical cores · c3-highcpu-8
22 vCPU 11 physical cores · c3-highcpu-22
03 Every limit is the processor
A bigger machine buys proportionally more.
On all three machines, ingest stopped at the processor, never at the disk, the network or memory. Each step up in vCPU raised the guaranteed rate at least in proportion: about 7,500 values per second for every vCPU on 4 and 22 vCPU, and 9,400 on 8 vCPU.
- Disk
- At most 42 MB/s written, on the 22 vCPU machine holding its maximum: a fraction of what its disk delivers.
- Memory
- Under 1 GB at every guaranteed rate, flat over ten minutes.
- Network
- 21 Gbit/s available and 0.1 ms between the load generator and the server.
Measured 2026-10-19, MaestroHub 3.0, Tier 1, Google Cloud c3-highcpu-4, c3-highcpu-8, c3-highcpu-22.
04 Above the limit
Slowed, not dropped.
- When devices send more than the machine can take, MaestroHub acknowledges each value more slowly. MQTT devices wait for those acknowledgements, so they send less and keep their values until there is room.
- Nothing that was acknowledged was dropped. In every ingest run of 19 October 2026, the broker dropped no values and the read-back found every acknowledged value in the historian.
- Pipeline runs that cannot start yet wait in a durable queue on disk, by default for up to one hour or 64 MiB. Past that, the oldest waiting runs are dropped and the Overview reports it; both limits are settings. None were lost in any pipeline run of this test.
What happens to data when your queue is full? Is it slowed, refused with a reason, or dropped without a trace? Ask for the test that shows it.
05 Pipelines
Runs per second with none lost. Each value from a device starts one run.
Swipe sideways to see every column
| What each run does | 4 vCPU | 8 vCPU | 22 vCPU |
|---|---|---|---|
| Pass-throughEach value starts a run that sets a field and publishes the result. | 8,000 runs/s | 15,000 runs/s | 27,000 runs/s |
| Computes for 20 msEach run spends 20 ms of processor time in JavaScript: heavy maths on every value. | 86 runs/s | 170 runs/s | 480 runs/s |
| Waits for 20 msEach run waits 20 ms, as when it calls a database or a web service. | 8,000 runs/s | 10,000 runs/s | 12,000 runs/s |
| In orderOne run at a time per pipeline, in arrival order, across 20 pipelines. | 4,400 runs/s | 10,000 runs/s | 12,000 runs/s |
Most pipelines run many values at once. When order matters, as for setpoints or counters, you switch a pipeline to in order: one run at a time, in arrival order. It costs throughput per pipeline, so you choose it where it is needed.
While taking in 65% of the guaranteed rate, about 3,500, 5,700 and 18,000 pass-through runs per second fit alongside on 4, 8 and 22 vCPU; or about 72, 130 and 360 runs per second that compute for 20 ms.
2,000 pipelines, each started once a second, finished with p99 12 ms on 4 vCPU, 5 ms on 8 vCPU and 2.5 ms on 22 vCPU. No run failed, and a read-back of sampled outputs held every value.
On 8 and 22 vCPU, waiting runs stopped at 256 runs in flight at once, the default, not at the processor. On 22 vCPU, pass-through and in-order runs stopped with a third of the processor still free: a limit in our code, which we are working on. In-order runs are one at a time per pipeline by design, so they scale with the number of pipelines (20 in this test).
Measured 2026-10-19, MaestroHub 3.0, Tier 1, Google Cloud c3-highcpu-4, c3-highcpu-8, c3-highcpu-22.
06 Size it
Plans with 30% headroom below the guaranteed rates measured on 19 October 2026.
07 How we tested
19 October 2026, MaestroHub 3.0, Google Cloud europe-west4.
Swipe sideways to see every column
| Server | 4 vCPU | 8 vCPU | 22 vCPU |
|---|---|---|---|
| Machine typeGoogle Cloud C3 | c3-highcpu-4 | c3-highcpu-8 | c3-highcpu-22 |
| CoresvCPU = logical cores = hardware threads | 4 vCPU = 2 physical × 2 threads | 8 vCPU = 4 physical × 2 threads | 22 vCPU = 11 physical × 2 threads |
| Memory capfor MaestroHub | 4 GB | 8 GB | 16 GB |
| Data diskits own Hyperdisk Balanced disk | 100 GB, 10,000 IOPS, 300 MB/s provisionedmeasured 10,572 IOPS, 301 MB/s | 100 GB, 15,000 IOPS, 500 MB/s provisionedmeasured 15,858 IOPS, 500 MB/s | 200 GB, 20,000 IOPS, 800 MB/s provisionedmeasured 21,147 IOPS, 800 MB/s |
- Processor
- Intel Xeon Platinum 8481C (4th generation), Google Cloud C3. MaestroHub was given every vCPU of its machine.
- What ran
- MaestroHub 3.0, Tier 1: Context Engine with its embedded MQTT broker and embedded time-series database, one machine. History kept 32 days.
- Load generator
- A separate c3-highcpu-22 in the same zone, less than half busy at every step, so the server was always the limit.
- Network
- 21 Gbit/s measured between the two machines, 0.1 ms round trip.
- Steps
- A ramp of one-minute steps until the server is full, then ten-minute holds: at the guaranteed rate on every machine, and at the maximum on 4 and 22 vCPU.
- Pass rule
- Every value stored and read back, p99 from publish to stored under 100 ms, processor under 80%, memory flat over the hold.
- Settings changed for the test
- Device ingest limits were switched off, to measure the machine rather than a setting. Out of the box, MaestroHub limits each device or gateway to 2,000 values per second and each workspace to 20,000, so one runaway device cannot flood a server. To take in more than 20,000 values per second in one workspace, raise the workspace limit. Also changed: logging at warning level, the web interface off, MQTT without TLS, and a licence without the trial's 10-pipeline limit. Everything else ran at its default.
And we will run the same test with you, on your hardware, before you size anything. Ask for a benchmark on your hardware.
08 Questions
Why are these numbers lower than the broker benchmarks I have seen?
A broker benchmark usually counts messages a broker passes from one client to another. We count a value only after MaestroHub has checked who sent it, checked it against its schema, stored it in the historian and published it live, and we read values back at the end to prove they are there. One value per message with QoS 1 is the hardest case for that path. When you compare figures, ask what each one counts.
What is a vCPU, and how many physical cores is that?
A vCPU is one logical core: one hardware thread. The Google Cloud C3 machines we used run two threads on every physical core, so 8 vCPU is 4 physical cores with two threads each, 4 vCPU is 2 physical cores and 22 vCPU is 11. MaestroHub was given every vCPU of its machine. When you compare with a server you own, count its threads, not its sockets.
My gateways send many values in one message. Does that change the numbers?
Yes, in your favour: a batched message costs the broker less work per value. We measured one value per message because it is the hardest case and the easiest to compare. We have not published batched figures; in the pilot we measure your own payloads.
What about MQTT QoS 0?
QoS 0 has no acknowledgement, so a device cannot know whether a value arrived, and nothing slows it down when the server is busy. Our rule is that every value is stored, so we test QoS 1, where each value is acknowledged.
Did you measure ARM machines?
Not yet. MaestroHub runs on arm64 as well as amd64, but every figure on this page is from Intel Xeon machines. We will publish ARM figures when we have measured them the same way.
What about Enterprise and Kubernetes deployments?
These figures are for Tier 1: Context Engine with its embedded MQTT broker and embedded time-series database on one machine. Tier 2 and Tier 3 use the same built-in broker with TimescaleDB, and are measured separately. Those results are not published yet.
When is a value acknowledged, and what does a crash lose?
A device's value is acknowledged only once it is written to the historian, so a device can trust every acknowledgement it gets; until then it keeps the value and sends it again after a reconnect. The built-in historian writes to disk within 100 ms: a clean stop or restart loses nothing, but a crash or a power cut can lose the last tenth of a second of acknowledged values. Where that must be zero, switch on synced writes, at some cost in throughput, or use TimescaleDB. Every figure on this page is with the default.
How long is history kept in this test?
The historian was set to keep 32 days, the longest window MaestroHub offers. MaestroHub keeps an operational window of 1, 7, 14 or 32 days per topic; long-term history goes to your own system of record.
We re-run this before every release.
And we will run the same test with you, on your hardware and your own data, in the six-week pilot. Then you size from your numbers, not ours.