What Are Time-Series Databases and When Should You Use One?
Learn what time-series databases are, how they differ from relational databases, and when to use one for metrics or IoT data.
Expected Interview Answer
A time-series database is a storage engine purpose-built for data points indexed by time, optimizing for high-volume append-only writes, time-range queries, and aggregation over time windows rather than general-purpose row lookups.
Unlike a general relational database, a time-series database assumes almost every write carries a timestamp and that most reads ask for a range ("last 24 hours") or a rollup ("average per minute"), so it stores data column-wise per metric, compresses repetitive numeric sequences aggressively, and indexes primarily by time rather than by an arbitrary primary key. This makes it the right choice for monitoring metrics, IoT sensor readings, financial ticks, and application telemetry, where ingestion rate is enormous, queries are almost always time-bounded, and old data is eventually downsampled or expired rather than updated in place. A general relational database can technically store timestamped rows too, but its row-oriented storage and general-purpose indexing struggle to keep up once write volume and retention scale into millions of points per day.
- Handles very high write throughput for timestamped data
- Fast range and aggregation queries over time windows
- Efficient compression for repetitive numeric sequences
- Built-in support for downsampling and retention policies
AI Mentor Explanation
A cricket broadcaster logs the speed, line, and length of every single delivery bowled across a five-day Test match, producing tens of thousands of timestamped readings. A general notebook that stores each ball as an unordered card becomes useless when the analyst asks for "average pace in the last session"; a scorebook organized strictly by over and minute answers that instantly. A time-series database is that time-ordered scorebook, built specifically so time-range questions are fast rather than an afterthought.
Step-by-Step Explanation
Step 1
Identify the write pattern
Confirm data arrives as a continuous, mostly append-only stream of timestamped values from sensors, metrics, or events.
Step 2
Confirm the query pattern
Check that most queries filter by a time range and aggregate (avg, max, sum) rather than looking up arbitrary rows by ID.
Step 3
Pick a time-series engine
Choose a purpose-built store such as InfluxDB, TimescaleDB, or Prometheus based on scale, SQL needs, and ecosystem fit.
Step 4
Plan downsampling and retention
Define rollup rules and retention policies up front, since raw high-resolution data grows unbounded otherwise.
What Interviewer Expects
- Clear articulation of the write/read pattern that justifies a specialized store
- Awareness of compression and storage-layout differences from row-oriented databases
- Concrete real-world examples: metrics, IoT, financial ticks
- Understanding that downsampling and retention are core, not optional, features
Common Mistakes
- Claiming any table with a timestamp column needs a time-series database
- Ignoring the write-throughput and compression advantages as the main driver
- Forgetting to mention downsampling and retention policies
- Not distinguishing time-series workloads from general OLTP workloads
Best Answer (HR Friendly)
“A time-series database is designed for data that comes in as a constant stream of timestamped values, like server metrics or sensor readings, where you mostly care about trends over time rather than looking up one specific record. I would reach for one when writes are extremely frequent and queries are almost always about a time range or an aggregate, since a general database was not built to handle that pattern at scale.”
Code Example
SELECT
time_bucket('1 minute', recorded_at) AS bucket,
device_id,
avg(temperature) AS avg_temp
FROM sensor_readings
WHERE recorded_at >= now() - INTERVAL '1 hour'
GROUP BY bucket, device_id
ORDER BY bucket;Follow-up Questions
- How does a time-series database differ from a general relational database internally?
- What is downsampling and why is it necessary for long-term storage?
- How do time-series databases achieve high write throughput?
- When would you NOT use a time-series database despite having timestamped data?
MCQ Practice
1. A time-series database is best suited for workloads where queries are mostly:
Time-series databases are optimized for filtering and aggregating data over time windows, not arbitrary key lookups.
2. Which is a defining characteristic of time-series workloads?
Time-series data is typically appended continuously with timestamps and rarely mutated after being written.
3. Why do time-series databases achieve strong compression?
Adjacent readings in a series tend to change gradually, so delta and specialized numeric encodings compress them efficiently.
Flash Cards
What is a time-series database? — A database optimized for storing and querying data points indexed by time, tuned for high-volume writes and time-range reads.
When should you choose one? — When data arrives as a continuous timestamped stream and queries are mostly time-range filters or aggregations.
Why not just use a relational database? — Row-oriented storage and general indexing do not scale to the write rate and compression needs of dense time-series data.
Name two common time-series use cases. — Infrastructure monitoring metrics and IoT sensor telemetry.