Data storage

Why

A sensor at 10 Hz makes about 315 million readings a year. Five years of that is over 1.5 billion rows for one signal. A chart can't draw that and shouldn't have to read it. But the usual fix, averaging, hides the one spike you were looking for.

How it works

When the loader inserts raw rows, two summary tables update in the same step. One groups each signal by minute, the other by hour. Each bucket stores five numbers: min, max, sum, sum of squares, and count. From those, Plexus can compute the average, the true high and low, and totals that stay correct at any zoom.

How long each tier is kept:

• Raw readings: your retention setting (7 days to 3 years)
• 1-minute summaries: 90 days
• 1-hour summaries: 5 years

Which tier serves which zoom

Charts in the app pick the tier from the time window you are looking at:

• 1 hour or less: raw readings. If the window holds more than 100,000 rows, Plexus buckets it at query time instead, into about 2,000 buckets as small as 10 ms, so dense logs keep their full span.
• Over 1 hour, up to 24 hours: 1-minute summaries. A full day is 1,440 points per signal.
• Over 24 hours: 1-hour summaries. Five years is about 43,800 points per signal, instead of 1.5 billion.

Spikes survive

Summaries keep min and max for every bucket, so a zoomed-out chart draws the real high and low as a band around the average. A one-sample spike in March still shows on a 5-year view.

The chart then fits the points to its width by thinning points per pixel. It splits the time axis into one bin per pixel column and keeps each bin's first, last, min and max. The shape you see matches the data at screen resolution.

Using it

Charts do this for you. Set a range in the time picker and the right tier is used. The API does the same: omit interval and it picks one that returns about a thousand points (raw under 10 minutes, then 1m, 10m, 1h or 1d). Pass interval to choose yourself.

curl "https://api.plexus.company/v1/sources/rover-02/metrics/query?metrics=battery.percent&last=7d" \
  -H "x-api-key: YOUR_API_KEY"
# -> "interval": "1h", "auto_downsampled": true
#    series with min, max, avg and count arrays

Limits

On the Free plan, charts and queries read the last 7 days, even though summaries exist longer. The 1-minute summaries are kept for 90 days, so minute-level detail on older data depends on raw readings still being inside your retention window.

How it works

Every reading takes the same path. Your device sends it to the Plexus gateway. The gateway stamps the time it arrived and queues it. A loader drains the queue in batches of up to 5,000 rows or every 2 seconds, whichever comes first, and writes them to storage. The loader only acknowledges a batch after the insert succeeds, so a failed insert is retried rather than dropped.

Raw telemetry lives in one table with two storage volumes. New rows land on local SSD. The table carries a rule: once a row's timestamp is 7 days old, move it to the cold volume, which is object storage. The database applies that rule during its normal background merges. Nobody runs a job and nothing is exported.

Using it

There is nothing to set up. Because hot and cold are two volumes of the same table, one query can span both. A chart that runs from yesterday back to last month reads fast disk for the recent part and object storage for the rest, and returns one series. The API works the same way.

Device events (faults, state changes, log lines) follow the same rule: 7 days hot, then cold.

You can see your split under Settings, on the Billing tab: total rows stored, how much sits in cold storage, and the date of your oldest data.

Details

The 7-day hot window is the same for every workspace. It does not change with your retention setting, and it is not billed on its own. Hot storage is covered by the ingest price. Cold storage is what the retention setting prices.

The 1-minute and 1-hour summaries that serve zoomed-out charts are separate tables that are not on the tiered policy, so they stay on local disk. A 5-year chart reads those summaries, not raw rows from cold storage.

Reads from cold storage are slower than reads from SSD. For zoomed-out views that rarely matters, because those views read the summaries.

How it works

Each column in the raw telemetry table has its own encoding, picked for the shape of its data:

• Timestamps: A device that reports every 100 ms produces gaps that are almost the same. Plexus stores how much each gap changed from the last one, which is usually close to zero and takes very few bits.
• Values: each reading is compared each reading with the one before and stores only the bits that changed. A temperature that moves slowly costs little.
• Device and signal names: stored once in a dictionary, and each row keeps a small number that points to it.
• Metadata and event text: general-purpose compression.

What it saved

We measured this on 27 August 2026 with 200 sources, 40 signals each, at about 10 Hz. We added ±40 ms of jitter to the timestamps, because real devices do not report on a perfect clock.

The timestamp column went from 4.0 to 1.1 bytes per row, 3.5x smaller. The whole row went from 21.3 to 13.4 bytes, 1.58x smaller.

Using it

Nothing to turn on. It applies to every row. Reads are the same: you query and chart compressed data exactly as before, and the numbers come back unchanged. The compression is lossless.

Smaller rows matter most where you pay for them. Storage beyond the 7-day hot window is what the retention setting prices, so the same budget holds more history.

Limits

Your ratio depends on your data. Steady clocks and slow signals compress best. Noisy signals, random timestamps and long free-text tags compress less. Treat our numbers as one realistic test, not a promise.

How it works

Your retention setting is saved on your workspace. When Plexus writes each row, it stamps that row with your window. The table's delete rule reads the stamp, so different workspaces expire on different schedules in the same table. If the loader does not know a workspace's setting, it keeps data longer rather than shorter.

For each option, the picker takes the bytes you store per day and projects your size at steady state. Only data older than the 7-day hot window is billed. Hot storage is covered by the ingest price.

Using it

Admins set this in Settings, on the Data tab, under Data retention.

• Each option shows an estimated monthly cost next to it. Your current window is marked Current.
• Longer: pick it and it applies right away. Your stored data grows toward the new estimate over the length of the window. It does not jump there next month.
• Shorter: you are asked to type "delete my data" first. Data outside the new window is deleted on the next storage merge, and recordings on the next daily sweep. Neither is instant, and deleted data cannot be recovered.
• The dialog shows about how much stored data falls outside the new window before you confirm.

What it covers

The setting applies to raw telemetry, device events and video recordings. The 1-minute summaries are kept 90 days and the hourly summaries 5 years either way, so long zoomed-out charts keep working after raw rows expire.

Your current window, cold storage size, oldest data date, and rows expiring in the next 48 hours show on the Billing tab.

Limits

Only admins can change retention. On the Free plan, charts and queries read the last 7 days. Workspaces created before this feature keep a 3-year window at no charge. Choosing any option, shorter or longer, moves them to metered storage billing, and the picker says so first.