Product · Benchmark
How much one MaestroHub server takes in, with nothing lost.
Measured on 14 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. 14 October 2026, MaestroHub 3.0, Google Cloud C3.
29,988values per second, every one stored
Maximum 49,605 per second. Limit: the processor.
59,909values per second, every one stored
Maximum 89,778 per second. Limit: the processor.
164,228values per second, every one stored
Maximum 199,011 per second. Limit: the processor.
Measured 2026-10-14 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,988 values/s | p99 52 ms from publish to stored3.1 of 4 vCPU busy · 0.65 GB memory | 49,605 values/s | Processor |
| 8 vCPU4 physical cores · c3-highcpu-8 · memory capped at 8 GB | 59,909 values/s | p99 28 ms from publish to stored5.7 of 8 vCPU busy · 0.73 GB memory | 89,778 values/s | Processor |
| 22 vCPU11 physical cores · c3-highcpu-22 · memory capped at 16 GB | 164,228 values/s | p99 26 ms from publish to stored16.0 of 22 vCPU busy · 0.82 GB memory | 199,011 values/srepeated: 198,387 | 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-14, 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 in proportion: about 7,500 values per second for every vCPU, on all three machines.
- Disk
- At most 54 MB/s written, on the 22 vCPU machine at 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-14, 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 14 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. | 4,400 runs/s | 9,800 runs/s | 19,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. | 3,500 runs/s | 8,000 runs/s | 10,000 runs/s |
| In orderOne run at a time per pipeline, in arrival order, across many pipelines. | 2,900 runs/s | 4,500 runs/s | 8,400 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.
On 4 vCPU while taking in 19,500 values per second, about 1,500 pass-through runs per second, or about 65 runs per second that compute for 20 ms, fit alongside.
On 4 vCPU, 1,000 pipelines each started once a second finished with p99 30 ms; 2,000 pipelines with p99 260 ms. No run failed, and a read-back of sampled outputs held every value.
On 22 vCPU, waiting runs stopped at 256 runs in flight at once, the default, not at the processor. In-order runs are one at a time per pipeline by design, so they scale with the number of pipelines (200 in this test).
Measured 2026-10-14, 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 14 October 2026.
07 How we tested
14 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,575 IOPS, 300 MB/s | 100 GB, 15,000 IOPS, 500 MB/s provisionedmeasured 15,864 IOPS, 500 MB/s | 200 GB, 20,000 IOPS, 800 MB/s provisionedmeasured 21,111 IOPS, 801 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. Out of the box, MaestroHub limits each device to 50 values per second and each workspace to 2,000, so one runaway device cannot flood a server. To take in the rates on this page, raise the workspace limit (per-device too, for fast devices). 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 an external broker and TimescaleDB and are measured separately. Those results are not published yet.
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.