In this chapter
We'll meet time-series data — measurements, metrics, tags, and timestamps as one real shape — and see why treating time as the organizing dimension, not just another column, is what makes this its own database category.
The Problem in Real Life
Mike wants real dashboards — sales climbing through the day, the delivery fleet's average speed, server response times, all of it watched live, not read a day later in a report. Sarah pulls up the old daily sales report to start: one row per day, a total, done.
That row can't answer the question Mike is actually asking. "How busy were we at 2pm?" isn't in it. The report only ever recorded a number and a date — never really when, just which day.
12,340 sold on May 20th. Sold when, though? All at once at midnight?
Mike
A Number Attached to a Day vs. A Number Attached to a Moment
A precise timestamp, not a rough date
A time-series measurement is paired with a specific moment — not just which day, but when, precisely.
Metrics and tags give it shape
A named metric (truck.speed), tagged with context (truck=T1) — so one slice can be queried back out later.
Time-series vs. relational/document
Other databases treat a timestamp as just another column. A time-series database organizes storage and querying around it first.
The same shape, everywhere
Sales, fleet speed, server health — different domains, the exact same underlying problem: a number that needs a precise "when."
What Makes Time-Series Data Different
Time-series data is exactly what the old report was missing: a value paired with a precise timestamp, not just a rough date. A measurement — a truck's speed, a server's response time, a sensor's temperature reading — is one specific number, at one specific moment, repeated constantly. This is different from an event, which records something happening (an order placed, a login) rather than a continuous quantity being sampled — this Act mostly deals in measurements, since that's what a dashboard genuinely watches.
Each measurement belongs to a metric — a named thing being tracked, like sales.count or truck.speed — and can carry tags (also called labels): extra key-value context, like which truck, or which region, letting GreenMart ask for just one slice of a metric later, not only the whole thing at once.
truck.speed is the metric. 42 and 55 are values. truck=T1 is a tag, letting this exact reading be filtered back out later by which truck it came from. at +0m/at +5m are timestamps — this simulator uses a relative clock (+Nm/+Nh/+Ns from an arbitrary starting point) since a one-shot script can't wait real minutes between points, but the shape is real: every point genuinely is metric + value + tags + timestamp, together.
INSERT truck.speed 42 truck=T1 at +0mINSERT truck.speed 55 truck=T1 at +5mQUERY truck.speed WHERE truck=T1
This is the actual shape every remaining chapter in this Act builds on — nothing about it changes, only what's done with it once there are thousands of these instead of two.
This is also where time-series vs. relational and time-series vs. document databases genuinely diverge, not just in syntax. A relational table or a MongoDB collection treats time as just another column or field — useful, but not special. A time-series database treats the timestamp as the organizing structure itself: how data gets stored, how it gets queried, even how old data eventually gets deleted, are all built around time first, not treated as one attribute among many.
That's not a small implementation detail. It's the actual reason this Act exists as its own database category, distinct from every other one this course has covered — GreenMart's sales, fleet speed, and server health are all, underneath, the exact same shape of problem: a number that means nothing without knowing precisely when it happened.
Key Takeaway
Time is not just another column when time is the dimension the entire workload is organized around. A time-series database doesn't just store a timestamp alongside a value — it builds storage, querying, and even deletion around time first, because that's what the actual questions being asked always come back to: not "what happened," but "what happened, and when."
Why This Matters
Every remaining chapter in this Act is really one consequence of this same realization, applied to a different part of the system: how writes get organized (next chapter), how a flood of points becomes a readable trend, how a late reading gets handled, and how too many tags can quietly become its own problem.
GreenMart's first real measurements exist — a truck's speed, tagged and timestamped, queryable by exactly which truck it came from. A single truck sending one reading every five minutes is easy. A whole fleet sending one every few seconds is a genuinely different problem, and exactly where the next chapter goes.