A time series database (TSDB) is a database built specifically to store and query data that’s tied to timestamps. This could include things like sensor readings, stock prices, server metrics, or IoT data. Basically anything where the when is just as important as the what.
Standard relational databases can technically store this kind of data, but they weren’t designed for it. Time series databases are optimized from the ground up for time-ordered data, which means they’re faster, more efficient, and more practical for time-heavy workloads.
How It’s Different from a Regular Database
In a regular database, you might query “what is the current temperature in Room 4?” In a time series database, the more common question is “what has the temperature in Room 4 been over the last 6 hours, and is it trending up?”
That shift in query pattern changes everything about how the database is structured. TSDBs are built around a few main ideas:
- Time is the primary index. Data is stored and indexed chronologically. This makes range queries (like getting all data between 9am and 11am) extremely fast.
- Writes are append-only. You’re almost never updating or deleting old records. New data just gets added to the end. This makes write performance very high.
- Data comes in fast and at scale. TSDBs are built to handle thousands or millions of data points per second without choking.
- Old data matters less over time. Most TSDBs support automatic downsampling, compressing older data into averages or summaries so you’re not storing billions of raw data points forever.
What Data Goes Into a Time Series Database?
If data has a timestamp and arrives frequently, it’s probably a good candidate for a time series database. Common use cases include:
| Use Case | Examples |
|---|---|
| Infrastructure monitoring | CPU usage, memory, network traffic across servers. |
| Application performance monitoring (APM) | Latency, error rates, request throughput. |
| IoT and sensor data | Temperature, pressure, GPS coordinates from physical devices. |
| Financial data | Tick-by-tick stock prices, trading volume, exchange rates. |
| Energy and utilities | Power consumption, grid load, meter readings. |
| Business metrics | Active users, conversion rates, revenue tracked over time. |
The common thread is usually high-frequency, time-stamped, often numerical data that you want to analyze as a series rather than as individual records.
Key Concepts You’ll Encounter
If you start working with a TSDB, you’ll run into the following terms constantly. Here’s what they actually mean:
| Term | What It Means |
|---|---|
| Metrics | The things you’re measuring (e.g., cpu.usage, temperature, http.requests). |
| Tags/Labels | Metadata that helps you filter and group data (e.g., host=server-01, region=us-east). Important for querying across large datasets. |
| Retention policies | Rules for how long data is kept before it’s deleted or downsampled. For example, raw data might be kept for 30 days, but hourly averages could be held for a year. |
| Downsampling/rollups | Automatically compressing high-resolution data into lower-resolution summaries over time. |
| Cardinality | The number of unique combinations of tags. High cardinality (millions of unique tag combos) is one of the most common performance challenges in TSDBs. |
Popular Time Series Databases
There are quite a few TSDBs out there, each with different strengths:
| Database | Best For |
|---|---|
| InfluxDB | One of the most widely used. Purpose-built for metrics and events with its own query language (Flux). |
| Prometheus | Open-source, very popular in Kubernetes and cloud-native environments; pull-based model. |
| TimescaleDB | Built on top of PostgreSQL. This enables you to use SQL while getting time series optimizations. |
| ClickHouse | Columnar database well-suited for analytical time series workloads at massive scale. |
| OpenTSDB | Older, built on HBase; common in large Hadoop environments. |
| QuestDB | Newer, high-performance, SQL-compatible. |
The right choice will depend on many things, including your scale, existing stack, and whether you need SQL compatibility.
When Should You Use a TSDB?
Not sure whether you need a time series database? You might consider it when:
- You’re collecting data points continuously over time (not just occasionally)
- Your queries are almost always time-ranged (“in the last hour”, “over the past week”)
- You need fast writes at high volume
- You want built-in features like retention policies, downsampling, or time-based aggregations
Skip it when your data isn’t time-centric, or when you’re dealing with complex relational data that requires joins and transactions.
It’s also important to point out that a TSDB won’t replace your primary relational database. Rather, it sits alongside it, handling the time-heavy workload.
The Bottom Line
A time series database is a specialized tool for the specific problem of storing and analyzing data where time is the central dimension. If you’re building anything that involves monitoring, observability, IoT, or financial data, a TSDB will almost certainly outperform a general-purpose database for those workloads. This would be true both in performance and in the quality of tooling available for time-based analysis.
It’s not a replacement for your main database though. It’s merely the right tool for a specific job.