Every metrics dashboard, IoT fleet, and observability pipeline eventually runs into the same problem: the database underneath it wasn’t built for the kind of data it’s being asked to store. Time-series data looks simple on the surface, just a timestamp, a value, and some tags, but at scale it breaks enough assumptions that an entire category of specialized databases exists just to handle it well.

The Shape of Time-Series Data

A time-series workload has a distinctive fingerprint. Writes are append-only and arrive in roughly time order. Reads are usually range scans over a time window, not lookups by primary key. Individual records are tiny, often just a few numbers, but the volume is enormous: a single fleet of servers or sensors can generate millions of data points per second. And almost nothing ever gets updated once written. You’re not editing yesterday’s CPU usage, you’re just adding today’s.

That combination, high write throughput, append-only inserts, time-ordered access, and eventual bulk deletion of old data, is different enough from typical transactional workloads that treating it like a general-purpose OLTP problem tends to fall apart under load.

Why General-Purpose Databases Struggle

A relational database indexed the normal way will happily ingest time-series data for a while, but a few things start to hurt as volume grows. B-tree indexes assume a reasonably even spread of keys, but time-series writes are monotonically increasing, which causes constant right-hand-edge insertion and index bloat. Row-oriented storage wastes space and I/O when queries typically want one or two columns (say, just the value) across millions of rows in a time range, rather than whole rows.

Retention is another mismatch. Time-series data is usually only valuable for a limited window, and old data needs to be dropped cheaply and continuously. Deleting rows one at a time in a traditional database is expensive; time-series engines are built to drop entire chunks or partitions of old data in constant time instead.

Compression and Downsampling

Because time-series values tend to be smooth and predictable (a temperature reading doesn’t jump wildly between two consecutive seconds), they compress extremely well with techniques like delta-of-delta encoding for timestamps and specialized numeric compression for values. This is a big part of why purpose-built time-series stores can achieve compression ratios that make storing years of high-resolution data practical, where a generic row store would need far more disk.

Downsampling is the other core technique: keeping full resolution for recent data, then automatically rolling older data up into coarser aggregates (hourly averages instead of per-second points). This is usually built into the database itself as a background process, rather than something an application has to manage by hand.

Cardinality: The Silent Killer

The single biggest operational risk in time-series systems isn’t volume, it’s cardinality. Every unique combination of tags (host, region, service, instance ID, and so on) creates a distinct series that the database has to track independently. A well-behaved metric with a handful of tags might have thousands of series. Accidentally including something like a user ID or request ID as a tag can explode that into millions, and most time-series engines degrade sharply once cardinality gets out of hand, because their indexing structures are optimized for a bounded, relatively stable set of series, not an ever-growing one. Most production incidents involving time-series databases trace back to a cardinality explosion rather than raw data volume.

Where This Leaves You

None of this means relational or document databases are wrong for time-stamped data in general, plenty of applications log timestamps without having a true time-series workload. The distinction matters when you have high-frequency, high-volume, append-mostly data with a natural expiration date. At that point, the specialized indexing, compression, and retention machinery that time-series databases are built around stops being a nice-to-have and starts being the difference between a system that scales and one that quietly falls over as data grows.