Metrics ticking in once a second, sensor readings, market ticks — if you're still storing them one document per data point in a regular collection, you're already paying for storage and query costs you don't need to. MongoDB 5.0 introduced Time Series Collections specifically for this kind of data.
Time series data shares a common shape: massive volume, highly repetitive structure, and rarely ever updated individually. Store it in a regular collection and every single measurement becomes its own document — field names repeated over and over, index entries growing one-to-one with data points, BSON overhead stacking up with every row. As volume climbs, storage cost grows faster than the data itself.
When a time series collection receives writes, it automatically groups multiple measurements that share the same time window and the same metadata into a single internal bucket document — holding up to roughly 1,000 data points, stored with columnar compression that dramatically cuts storage size. At query time, MongoDB automatically "unpacks" the bucket so you still see the familiar, per-document structure you'd expect — the whole mechanism is completely transparent to the user.
The required timestamp field — it places each point on the timeline and is the core basis for how bucketing happens.
The field used for grouping — a device ID, hostname, or metric name. Points sharing the same meta are more likely to land in the same bucket.
seconds / minutes / hours — sets how much time span a single bucket covers, and should match your actual write frequency.
Creating a time series collection just means passing an extra timeseries option to createCollection. Reading and writing after that looks almost identical to a regular collection.
Time series collections aren't a universal fix, but whenever data fits the shape of "high-frequency writes, organized by timestamp, almost never randomly updated," they're very likely the better answer.
Thousands of devices reporting temperature, humidity, location, and more every second.
CPU, memory, latency, QPS — the kind of operational metrics collected second by second.
High-frequency quote and trade records, demanding both high write throughput and fast range queries.
User behavior or system events generated in chronological order and almost never revised afterward.
This is exactly why WAP itself stores its own cluster monitoring metrics in a time series collection — the millions of metric points generated every day would cost several times more to store without bucket-based compression.
Time series collections solve a data-modeling problem. Whether the cluster underneath stays stable — and whether anyone has to get out of bed at 3 a.m. for it — is a separate job. That one belongs to Whaleal Platform.