Both decimation and compression shrink a time-series stream by keeping fewer points, but they are not the same thing and confusing them leads to bad data. Decimation blindly keeps every Nth sample; compression intelligently keeps the points that matter. This guide sharpens the boundary the compression pages assume but rarely state, explaining why naive decimation drops spikes and creates aliasing, and how deadband and swinging-door compression avoid those traps.
Decimation vs Compression in one line: Decimation reduces data by keeping every Nth sample and discarding the rest on a fixed schedule, regardless of what the signal is doing. Compression reduces data by keeping the samples that carry real information and dropping only the ones that can be reconstructed within a bounded error. Decimation is blind and can lose spikes or alias a signal; deadband and swinging-door compression are signal-aware and preserve meaningful events.
Decimation is uniform and content-blind. To decimate a stream by a factor of ten, you keep one sample and throw away the next nine, then repeat, no matter what happened during those nine. The rule is fixed in time and never looks at the values, which makes it trivially cheap and completely predictable in how much data it removes. It is the crude answer to too much data: just keep less of it, evenly.
Compression is content-aware. Deadband and swinging-door algorithms look at each sample and ask whether dropping it would lose real information - whether the value can be reconstructed later within a chosen tolerance from the points that are kept. If yes, the sample is discarded; if not, it is retained. The number of points kept is not fixed; it flexes with the signal, keeping many points through a fast transient and few through a flat stretch. Compression spends its storage where the data is actually changing.
The distinction is easy to blur because both produce a thinner stream, and on a slowly varying signal they can even look similar. But their logic is opposite. Decimation decides what to keep by the clock; compression decides by the data. That difference is invisible when the signal is calm and glaring the moment something happens fast, which is exactly when the data matters most.
The first failure of decimation is dropped spikes. A pressure spike, a brief alarm excursion, or a fast transient that lives entirely within the nine discarded samples simply vanishes - decimation had no way to know it was there, because it never looked. The reconstructed trend is smooth and shows nothing wrong, even though a real event occurred. For process data, silently deleting the exact excursions an operator most needs to see is the worst possible loss.
The second and subtler failure is aliasing. Uniformly sampling a signal that varies faster than the sampling rate does not just miss detail - it can make a fast oscillation appear as a slow one that was never real. Decimate a cyclic signal without regard for its frequency and the leftover samples can trace a smooth, plausible, and entirely fictitious trend. The archive looks clean and reasonable while misrepresenting the underlying behavior, which is far more dangerous than an obvious gap because nothing signals that anything is wrong.
Compression is designed to avoid both. Because swinging-door keeps a point precisely when dropping it would let the reconstruction drift outside the deviation, a spike forces points to be retained rather than lost - the excursion survives because ignoring it would break the error bound. And because retention is tied to the signal's behavior rather than a fixed clock interval, compression does not manufacture aliases the way uniform decimation does. The bounded error that makes compression lossy is exactly what makes it safe where decimation is not.
In SCADA and historian practice, compression is the right tool for reducing what gets stored, because it protects the events operators and engineers actually care about. Storing a remote wellhead pressure with a bounded-error deviation keeps every real swing and spike while dropping the noise, so the archive is both small and trustworthy. Decimating that same signal to save space would risk deleting the excursion that precedes a problem - a false economy on data that exists precisely to catch such events.
Decimation still has legitimate uses, but on the display side rather than the storage side. When a chart has to render a year of data in a few hundred pixels, some downsampling is unavoidable, and a good platform reduces for display without harming the stored archive - and ideally in a way that preserves the extremes in each interval rather than blindly keeping every Nth point, so a spike still shows up on the zoomed-out view. The rule of thumb is: compress on the way into the archive, downsample only on the way out to a screen, and never decimate the source of truth.
Merobix compresses process data into the archive with a per-tag bounded-error deviation, so the stored record keeps meaningful changes and spikes rather than a blind sample of them. For long-range trends it reduces data for display without degrading the underlying archive and while preserving interval extremes, so a decade-wide view still reveals a transient - keeping the archive faithful while the chart stays fast.
Decimation keeps every Nth sample on a fixed schedule and discards the rest without looking at the values, so the amount removed is predictable but the choice of what to keep is blind. Compression keeps the samples that carry real information and drops only those that can be reconstructed within a bounded error, so it retains many points through a transient and few through a flat stretch. Decimation reduces by the clock; compression reduces by the data.
Because it never examines the values it discards. A spike that lives entirely within the discarded samples simply disappears, leaving a smooth trend that hides a real event. Worse, uniformly sampling a signal that varies faster than the sample rate can make a fast oscillation appear as a slow, fictitious one - aliasing - producing a clean-looking archive that misrepresents reality. Compression avoids both by retaining points whenever dropping them would break the error bound.
Yes, but on the display side, not the storage side. Rendering a year of data in a few hundred pixels requires some downsampling, and a good platform reduces data for a chart without touching the archive, ideally preserving the minimum and maximum in each interval so spikes still appear. The principle is to compress data into the archive and only downsample on the way out to a screen, never decimating the stored source of truth.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.