Time-series data has a hidden regularity that makes it exceptionally compressible: timestamps march forward at nearly steady intervals, and consecutive values usually differ only slightly from the ones before. Inline compression is the set of on-disk encoding schemes that exploit that regularity to store the same points in a fraction of the space. Crucially, it does this without throwing any data away - unlike deadband or swinging-door compression, which drop points, inline compression keeps every point and simply encodes them more cleverly, so what you read back is exactly what was stored.
Inline Compression in one line: Inline compression is the on-disk encoding a time-series database applies to shrink storage while keeping every data point exactly. It typically encodes timestamps with delta or delta-of-delta encoding, storing only the tiny differences between the near-regular intervals, and encodes values with schemes like XOR of consecutive floats or run-length encoding of repeated readings. Because it stores differences rather than full values and packs long runs compactly, it can reduce time-series storage dramatically, and unlike lossy historian compression it is lossless - it drops nothing and reconstructs the original points precisely.
The timestamps in a time series are the easiest thing to compress, because they are almost perfectly predictable. A tag sampled every ten seconds produces timestamps that step by ten seconds again and again, so storing each full timestamp as an absolute value wastes enormous space repeating information that barely changes. Delta encoding stores the first timestamp in full and then only the difference from the previous one - here, ten seconds, over and over - which is a far smaller number to record. Instead of a long absolute time on every row, you store one full time and a stream of small deltas.
Delta-of-delta encoding goes one step further and compresses the deltas themselves. If the interval is steady at ten seconds, the difference between one delta and the next is zero, so the delta-of-delta stream becomes a long run of zeros, which packs down to almost nothing. Only when the interval actually changes - a missed sample, a jitter in timing, a different scan rate - does a non-zero delta-of-delta appear. This is why perfectly regular timestamps compress to nearly free: the encoding spends bits only on the moments the rhythm breaks, and says almost nothing during the long stretches where it holds steady. Real telemetry, with its near-regular but slightly jittery timing, sits right in the sweet spot for this scheme.
This kind of encoding is inherently columnar, meaning it stores all the timestamps together and all the values together rather than interleaving them row by row. Keeping like next to like is what lets these schemes work, because a column of near-identical deltas or slowly changing values compresses far better than a mixed row of a timestamp and a float. Time-series databases lean on this columnar layout precisely so that the timestamp column and each value column can each be encoded with the technique best suited to it, which is a big part of why they store time-series data so much more compactly than a general-purpose row store would.
Values need different treatment from timestamps, because they do not step by a fixed amount, but they are still highly compressible thanks to a simpler fact: consecutive readings are usually close to each other. A well-known technique for floating-point values, popularized by the Gorilla compression approach, is to XOR each value's bit pattern with the previous one. When two consecutive floats are similar, most of their bits match, so the XOR result is mostly zeros, and those zeros can be encoded in very few bits. A slowly drifting temperature or pressure therefore compresses tightly, because each new value differs from the last only in a handful of low-order bits, and the encoder spends space only on that handful.
Run-length encoding handles the other common pattern: values that repeat. A status tag that reads the same state for hours, a setpoint that holds unchanged, or an analog signal that sits flat produces long runs of identical values, and run-length encoding collapses each run into a single value plus a count - storing 'this value, five thousand times' instead of the value five thousand times over. Combined with the delta and XOR schemes for the timestamps and the changing values, this means that a tag which is mostly steady with occasional movement compresses about as well as its information content deserves: near-nothing for the flat stretches, a little more where it actually changes.
The essential property tying all of these together is that they are lossless. Delta encoding, delta-of-delta, XOR, and run-length are all reversible transformations - decoding them reconstructs the original timestamps and values bit for bit. This is the sharp line between inline compression and the lossy historian techniques that discard points to save space. Inline compression never asks whether a point is worth keeping; it keeps every point and just represents them more efficiently, so a query gets back exactly the data that was recorded. A system can use both - lossy filtering to decide which points to store, then inline encoding to store those points compactly - but they are doing fundamentally different jobs.
SCADA historians benefit enormously from inline compression because their data is exactly the near-regular, slowly changing kind these schemes were designed for. Scan-based tags produce steady timestamps that delta-of-delta encoding reduces to almost nothing, and physical measurements like pressure, temperature, and level drift smoothly enough that XOR encoding captures each new value in a few bits, while status and setpoint tags sit flat for long stretches that run-length encoding collapses. Across many tags and many sites, storing years of history at full fidelity would be prohibitive without this encoding, and lossless inline compression is what makes keeping every recorded point affordable.
A cloud SCADA platform such as Merobix stores telemetry from many remote sites at scale, and inline compression is a foundational reason that is economical. Because the encoding is lossless, the platform can keep the exact points it received - honoring the fidelity of the field data - while still storing them in a small fraction of their raw size, so operators get back precisely what was measured and the storage bill reflects the data's true information content rather than its uncompressed bulk. This complements, rather than competes with, any lossy filtering applied at the edge: a remote device may already send only meaningful changes to save bandwidth, and inline compression then stores those changes compactly in the historian.
For field operations the practical effect is that fidelity and cost stop being in tension. There is no need to sacrifice detail to control storage, because inline compression shrinks faithful data rather than discarding it, so a historian can retain full-resolution history across a large fleet without the storage growing in proportion to the raw sample count. Understanding that inline compression is lossless - that it makes data smaller without making it worse - is what lets an operator trust that a compact historian is nonetheless an exact record of what the field instruments reported.
Inline compression is lossless. Delta, delta-of-delta, XOR, and run-length encoding are all reversible, so decoding reconstructs the original timestamps and values exactly, bit for bit. This is the key difference from lossy historian techniques like deadband or swinging-door compression, which reduce storage by discarding points. Inline compression keeps every point and simply encodes them more efficiently, so a query returns precisely the data that was recorded.
Because they are nearly regular. A tag sampled at a fixed rate produces timestamps that step by the same interval repeatedly, so delta encoding stores just that small, constant difference instead of a full absolute time on every row. Delta-of-delta encoding then compresses the deltas themselves, turning a steady interval into a long run of zeros that packs down to almost nothing. The encoding only spends bits when the timing actually changes, which is why regular timestamps become nearly free to store.
They shrink storage in fundamentally different ways. Deadband and swinging-door compression are lossy filters that decide which points are worth keeping and drop the rest before storage, so some original points are gone forever. Inline compression is a lossless encoding that keeps every point and represents it more compactly using differences and run-lengths. A system can use both together - lossy filtering to choose which points to store, then inline encoding to store those points efficiently - because they address different stages of the same goal.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.