We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Database Types Storage
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Database Types Storage
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Your server sends a CPU reading every 10 seconds. Your IoT temperature sensor reports every 30 seconds. Your stock trading platform records a price tick every millisecond.
All of these produce the same pattern: a timestamp paired with one or more values, arriving continuously, in order, forever. Over a day, a single server emits 8,640 CPU readings. A fleet of 10,000 servers emits 86 million. Over a year, that's 31 billion data points, and that's just one metric.
Can you store this in PostgreSQL? Technically, yes. Create a table, add a timestamp column, insert away. But at 31 billion rows, your INSERT craters, your analytical queries (average CPU over last 24 hours, grouped by server) take minutes, and your storage costs explode because PostgreSQL stores every row like a precious unique snowflake.
Time-series databases are built specifically for this pattern. They exploit the unique properties of timestamped data, it's append-only, mostly immutable, queried by time ranges, and benefits enormously from time-based compression, to deliver 10-100x better performance than general-purpose databases for these workloads.
Time-series data has properties that general-purpose databases don't optimize for:
1. Append-only. You almost never update or delete historical readings. You don't go back and change last Tuesday's CPU reading. Data arrives, gets written, and stays there.
2. Time-ordered. Data naturally arrives in chronological order. Queries almost always include a time range: "show me the last hour," "compare this week to last week."
3. High cardinality metadata. Each data point has tags/labels: server=web-03, region=us-east, datacenter=dc1. Queries filter and group by these tags.
4. Downsampling. Yesterday's per-second data is useful for debugging. Last year's per-second data is not. You want to automatically roll up old data, keep 1-second granularity for the last day, 1-minute for the last month, 1-hour for the last year.
5. Massive write volume. A typical monitoring setup might ingest millions of data points per second.
Time-series databases exploit every single one of these properties:
| Property | Optimization |
|---|---|
| Append-only | LSM-tree or append-only write path, no random updates |
| Time-ordered | Store data in time-sorted blocks for sequential reads |
| High-volume writes | Write-ahead log + batch compression |
| Time-range queries | Partition data by time (hourly, daily chunks) |
| Downsampling | Built-in retention policies and continuous aggregates |
| Compression | Delta-of-delta for timestamps, gorilla encoding for floats |