System specs

The reference workload on this page is 10 kHz across 100 channels — one million values a second, into a single dataset, on one on-prem server.

The short answer:

The rest of this page is the arithmetic, so you can check it against your own duty cycle rather than take the claim on faith.

The server

One machine. Sized for on-prem, where you buy the box once and want it to still be the right box in two years.

Two things about that table are worth saying out loud:

• The data disk is separate, and it is the component that matters. Telemetry is written continuously and read in bulk; keep it on its own NVMe device rather than sharing the system disk. Its size is what decides how much history you keep, and nothing else on this page changes that.
• Everything else runs on that one machine. The software layers are installed and tuned during deployment; you do not size them separately, and they are not your problem to operate.

Against that hardware, the reference workload is a small fraction of the box:

The headroom is deliberate. A server that runs at 90% of its disk throughput on the day it is installed is a server that fails the first time somebody adds a second test stand.

What it absorbs

Each row costs about 900 bytes on disk — 800 for the hundred float64 readings, the rest for the timestamp, the dataset reference and the index entry that makes it findable. At 10,000 rows a second that is ≈ 32 GB per hour of recording, before compression.

That number, not throughput, is what decides how long you go without touching anything.

How much it holds

Storage is a function of hours actually recorded, not calendar time:

Telemetry is compressed automatically once an hour of data has closed, so the steady-state figure is the compressed one. At the conservative 5×:

The second column is the peak case: compression only helps after data has settled, so one continuous session writes at the raw 32 GB/hour until it does. Even so, a 2 TB disk swallows a 62-hour unbroken run of 10 kHz × 100 channels. No realistic test campaign gets near it.

Read the first column against your duty cycle:

Twelve hours of 10 kHz × 100-channel recording every week, for six months, on the recommended 2 TB disk, with nothing touched. At 10× compression — common for smooth analog telemetry — double every figure in the table.

When you do eventually reach the end of the disk, none of the answers is a migration:

100 channels is not a special case

Nothing widens when you go from 8 channels to 100. Each dataset gets its own storage table at registration, with one column per declared channel:

time         timestamp
dataset_id   uuid
ch_0         float64
…
ch_99        float64

So "does 100 channels need a migration" has a flat answer: no, because the storage shape is created per dataset from the channel list you send. There is no shared telemetry table whose schema anyone has to change.

Measured against projected

Be clear about which parts are proven:

The pipeline has been run at twice the reference row rate with no loss and no duplicates. Rows per second is what the writer's per-batch overhead scales with — the batching, the flush timer, the duplicate check — and 10 kHz sits comfortably inside proven territory.

The untested axis is width: 12.5× the bytes per row through the same bulk write path. Bytes per second is the axis to watch, and at ≈ 20 MB/s it is using about 4% of the recommended disk. There is room, but it is a projection, not a measurement.

Burst tolerance

Producers do not write to the disk directly. A durable buffer sits in between, so a slow disk, a restart or a maintenance window costs latency rather than data:

Frames are acknowledged only after the data is committed, so an interrupted consumer replays rather than loses. Replayed rows collapse onto the rows they already wrote — a duplicate is never a duplicate row.

Where the JSON path caps out

The reference workload assumes streaming. Sustaining 10 kHz over HTTP append is a different proposition, and the honest arithmetic is:

That last row is the one that bites. A request that wide is split into nine internal statements of 588 rows each, every value is written individually rather than as a bulk stream, and every row carries its own timestamp instead of sharing one base timestamp and a sample period across a whole frame.

HTTP append remains right for backfills, slow sensors and anything a person triggers, up to a few hundred rows a second. Above that, streaming is not an optimisation, it is the supported path — and switching does not change the data model: same dataset, same ch_N columns, same channel list.

What would actually force a change

Three triggers, in the order you are likely to meet them:

Query load is the wildcard none of the above covers: reads on recent data share the same machine as the writer. Bulk reads already downsample server-side for exactly this reason, but a dashboard polling a live 10 kHz dataset is spending from the same budget as the ingest — which is the other reason the recommended core count is what it is.

Checking it yourself

A support bundle reports every dataset's storage table with its estimated row count and total size on disk. Two bundles a week apart give you your real growth rate — the one number this page cannot predict for you.