Status: DRAFT — product / sales-enablement copy, benchmark-backed. For human review before external use.
Applies to: Pulse Historian · edge/on-prem + managed cloud
Source of figures:Pulse_Historian_Benchmark_Report.xlsx(ExactSpace, 2026-07-02). Engineering detail: dev/internals/benchmarks.md.
A single, honest source for performance messaging: punchy enough for a landing page, careful enough for a technical proposal. Every number below is measured on real hardware, and we say exactly how.
The benchmark ran on two machines that stand in for the two ways Pulse Historian is deployed:
Pulse Historian sustained a full 50,000-tag plant streaming at 1 sample/second — with zero dropped points — on both an ordinary workstation and a small cloud VM. Bulk history loaded at 1–1.6 million points/second, and reads stayed sub-second for realistic queries with no errors under concurrent load.
| Result | In plain terms | |
|---|---|---|
| Live capture | 50,000 tags @ 1 Hz, 0 dropped | A whole plant's fast-sampled tags, captured live and losslessly |
| Bulk backfill | 1.0–1.66 M points/sec | Years of history loaded in minutes |
| Query speed | sub-second typical single-tag reads | A month of 1-second data for a tag in well under a second |
| Concurrency | hundreds of queries/sec, 0 errors | Many dashboards and an AI copilot reading at once |
| Hardware | an 8-core PC or a small cloud VM | No cluster required to get started |
Measured on a workstation PC (Ryzen 7 7800X3D, 32 GB, NVMe) and a cloud VM (4-core, 64 GB). See Methodology & honest caveats.
Three deliberate engineering choices, in plain language:
It stores data as a dense grid, not a pile of rows. Every sample is a fixed 4-byte slot whose position is its timestamp — so there's no per-row bookkeeping, no index to chase, and no timestamp stored twice. Reads are a straight memory scan.
It reads straight from memory-mapped files, in parallel. The operating system maps history files directly into memory; every core scans a different slice at once. There's no query-planner overhead between you and the bytes.
The same engine captures and serves. The engine (Pulse Chronos) that ingests millions of points per second is the same one that answers dashboard and copilot queries — no separate analytics warehouse, no nightly ETL.
Target: 50,000 tags each sending one sample per second (50,000 points/sec, sustained).
| Workstation PC (edge) | Cloud VM (managed) | |
|---|---|---|
| Sustained rate | 47,908 pts/s | 46,570 pts/s |
| Run length | 60 minutes | 12 hours |
| Dropped points | 0 | 0 |
| CPU (avg) | 36% | 10% |
Both machines held the full 50,000-tag firehose for the entire run without dropping a single point — the workstation over an hour, the cloud VM over half a day. This is the number that matters for "will it keep up with my plant": yes, on commodity hardware, with headroom to spare.
Loading historical data as fast as the engine accepts it:
| Workstation PC | Cloud VM | |
|---|---|---|
| Ingest rate | 1.0 M points/sec | 1.66 M points/sec |
At these rates, a multi-year backfill of a large tag set completes in the time it takes to fetch it from the source system, not overnight.
Median time to read a range of 1-second data:
| Query | Workstation PC | Cloud VM |
|---|---|---|
| 1 tag · 1 day (86 k points) | 44 ms | 7 ms |
| 1 tag · 1 month (2.6 M points) | 359 ms | 61 ms |
| 100 tags · 1 day (8.6 M points) | 409 ms | 199 ms |
| 100 tags · 1 month (259 M points) | 11.7 s | 6.5 s |
Everyday queries — a tag over a day or a week, a dashboard's worth of tags over a day — return in tens to hundreds of milliseconds. Only the extreme pulls (100 tags across a full month of per-second data — hundreds of millions of points) reach into seconds, and the cloud VM's larger memory roughly halves those.
Repeated 1-hour, 10-tag queries fired in parallel:
| Concurrent readers | Workstation throughput | Cloud VM throughput | Errors |
|---|---|---|---|
| 8 | 142 req/s | 584 req/s | 0 |
| 16 | 143 req/s | 587 req/s | 0 |
| 64 | 120 req/s | 587 req/s | 0 |
Zero errors at every level on both machines. The cloud VM sustained ~587 requests/second flat out to 64 concurrent readers — comfortable headroom for many live dashboards plus a Pulse Copilot querying context repeatedly.
| If you care about… | Pulse Historian gives you… |
|---|---|
| Lossless high-rate capture | A full 50,000-tag, 1-second plant sustained with zero dropped points — on a single ordinary machine. |
| Fast historical loads | Million-plus points/second backfill, so onboarding years of history is a short job, not an overnight batch. |
| Live dashboards & ad-hoc queries | Tens-to-hundreds-of-milliseconds responses for everyday multi-tag queries. |
| Many concurrent users + AI copilot | Hundreds of queries/second with no errors under load. |
| Modest hardware budgets | These numbers came from an 8-core PC and a small cloud VM — you don't buy a cluster to get started. |
Strong numbers only help if buyers trust them. Here is exactly what was and was not tested (full detail: engineering benchmark page).
Test setup. Two machines: a workstation PC (AMD Ryzen 7 7800X3D, 8-core, 32 GB, NVMe SSD, Windows 11) and a cloud VM (4-core, 64 GB, premium SSD, Linux), each tested on its own (client and server local to the machine). Write tests used 1-second sampling; read windows were computed at 1-second resolution.
What this means when reading the figures:
What we deliberately do not claim here:
Drop-in lines for the landing page, decks, and proposals — each backed by the figures above. Keep the methodology note nearby in technical contexts.
Headline / hero:
Stat callouts:
Reviewer checklist before external publication: (1) confirm you're comfortable citing single-node / local-transport framing; (2) keep the methodology note attached to any stat used in a technical proposal; (3) do not quote a compression ratio or an aggregation-speed number until those are separately measured; (4) all figures trace to
Pulse_Historian_Benchmark_Report.xlsx(2026-07-02) — re-verify against the latest report before publishing.