We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Database Types & Storage
A database optimized for time-stamped data points like metrics, sensor readings, and financial ticks. InfluxDB and TimescaleDB are purpose-built for this.
In short
A time-series database is a database built specifically to store and query data points that are stamped with a time, such as server metrics, IoT sensor readings, and stock prices. It is optimized for high write rates, fast range queries over time windows, and automatic downsampling and expiry of old data, with InfluxDB, TimescaleDB, and Prometheus being the common choices.
In short
A time-series database is a database built specifically to store and query data points that are stamped with a time, such as server metrics, IoT sensor readings, and stock prices. It is optimized for high write rates, fast range queries over time windows, and automatic downsampling and expiry of old data, with InfluxDB, TimescaleDB, and Prometheus being the common choices.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Time-Series Database across a run of lessons, not one page. These 4 alone are about 115 minutes of step-by-step reading, every one with a quiz.
Databases built for timestamped data, metrics, IoT sensors, financial ticks, and observability.
Design a metrics collection and monitoring system - time-series databases, aggregation pipelines, alerting, and dashboards at scale.
Data points indexed by time, the heartbeat of every monitoring system.
Partitioning by contiguous value ranges, the go-to strategy for time-series data, logs, and anything with a natural ordering.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Time-Series Databasespay once,
yours for life
A time-series database (TSDB) stores measurements that arrive in time order. Each record is a value plus a timestamp plus some labels that say where it came from. For example: cpu_usage = 73.2 at 14:05:01 on host web-03 in region us-east. Over a day a single server can produce millions of these points, and a fleet of thousands of servers produces billions.
The defining trait is that writes are almost always appends of new, recent data, and reads are almost always queries over a time range like the last 5 minutes or the last 30 days. You rarely update a point after it was written, and you rarely look up a single point by an arbitrary id. A TSDB is tuned hard around that pattern, which is why a general purpose relational table with a timestamp column eventually struggles at scale.
Common TSDBs include InfluxDB, TimescaleDB (a Postgres extension), Prometheus (for monitoring), and Amazon Timestream. ClickHouse and Apache Druid are column stores that are also frequently used for time-series workloads.
Because data arrives in time order and is rarely changed, a TSDB can store it in large append-only blocks sorted by time. New points go into an in-memory buffer, are written to a write-ahead log for durability, and are periodically flushed to immutable on-disk blocks. This keeps writes cheap and avoids the random-write overhead that hurts B-tree indexes when you constantly insert recent rows.
On disk the data is usually stored column by column rather than row by row, so all the cpu_usage values sit next to each other. Columnar layout compresses extremely well for time-series because consecutive values are similar. Techniques like delta-of-delta encoding for timestamps and XOR compression for floats, from Facebook's Gorilla paper and used by Prometheus and InfluxDB, can shrink data by 10x or more.
Old blocks are compacted and merged in the background. Most TSDBs add retention policies that automatically delete data past a cutoff, and continuous downsampling that rolls raw points into 5-minute or 1-hour summaries so long-range queries stay fast. Labels are indexed separately (an inverted index) so you can quickly find all the series matching host=web-03 without scanning everything.
If you need to design one, for an interview or for real, the full walkthrough is in Design a Time-Series Database: the schema, the write path, compression with worked numbers, rollups, retention and sharding.
Reach for a TSDB when your data is naturally a stream of timestamped measurements and your queries are time-bounded: infrastructure monitoring, application metrics, IoT and sensor telemetry, financial ticks, event analytics, and real-time dashboards. The payoff is high ingest throughput, strong compression, and built-in time functions like rate, moving average, and bucketed aggregation.
The trade-offs are real. A TSDB is not a general purpose store. Updating or deleting individual points is slow or unsupported. High-cardinality labels (for example, a unique user id attached to every metric) can blow up the index and memory use, which is the single most common way teams break Prometheus and InfluxDB. Joins across unrelated datasets are weak compared to a relational database.
A useful middle path is TimescaleDB, which runs inside PostgreSQL. You keep full SQL, joins, and your existing tooling, and the extension transparently partitions tables into time-based chunks for TSDB-style performance. If you already run Postgres, that often beats adopting a separate system.
Picture a monitoring setup for 2,000 servers. Each server reports about 200 metrics every 15 seconds. That is 2000 x 200 / 15, roughly 26,000 points per second, around 2.3 billion points per day. A row-per-point relational table with an index would spend most of its time on index maintenance and would balloon in size.
Prometheus or InfluxDB ingests this comfortably on a single node. It compresses the 2.3 billion daily points down to a few gigabytes, answers a dashboard query like average CPU per region over the last hour in milliseconds, and automatically drops raw data after 15 days while keeping 1-hour rollups for a year. A query language function such as rate(http_requests_total[5m]) computes per-second request rates from a counter without you writing windowing logic by hand.
This is the workload Grafana dashboards are built on: a TSDB underneath, a label-based query on top, and time on the x axis.
Prometheus
The de facto standard for Kubernetes and infrastructure monitoring; scrapes metrics into its own embedded TSDB and queries them with PromQL.
InfluxDB
Purpose-built TSDB used for DevOps metrics and IoT telemetry, with its own columnar storage engine and retention/downsampling policies.
TimescaleDB
A PostgreSQL extension that turns ordinary tables into time-partitioned hypertables, giving TSDB performance while keeping full SQL and joins.
Amazon Timestream
AWS managed serverless TSDB that automatically tiers recent data to memory and older data to cheaper storage for IoT and operational metrics.
A relational database is built for arbitrary inserts, updates, and joins on rows looked up by key. A TSDB assumes data arrives in time order, is almost never updated, and is queried over time ranges, so it uses append-only columnar storage, time-aware compression, and automatic retention. That makes it far faster and smaller for metrics, but worse at point updates and cross-table joins.
Cardinality is the number of unique label combinations, which equals the number of distinct time series you create. Each unique combination of labels like host plus region plus path is a separate series with its own index entry. Attaching a high-cardinality label such as a user id or request id to every metric can create millions of series and exhaust memory, which is the most common cause of Prometheus and InfluxDB outages.
For small or low-frequency data, yes, that is perfectly fine. The problems show up at high ingest rates and large volumes, where index maintenance, table bloat, and slow range scans appear. If you want TSDB behavior without leaving Postgres, use the TimescaleDB extension, which time-partitions the table for you while keeping standard SQL.
Downsampling rolls many raw points into fewer summary points, for example replacing 15-second samples with 1-minute averages, minimums, and maximums. It lets you keep recent data at full detail while storing months of history cheaply, so long-range dashboard queries read far fewer points and stay fast.
Yes. Prometheus is a monitoring system that includes its own embedded TSDB. It pulls metrics from targets, stores them locally in time-ordered compressed blocks, and queries them with PromQL. For long-term storage across many nodes, teams often pair it with Thanos, Cortex, or Mimir.
The industry examples in “The next question”:
NoSQL
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
Stream Processing
Processing data continuously as it arrives, rather than in batches. Powers real-time analytics, fraud detection, and live dashboards.
Observability
The ability to understand a system's internal state from its external outputs. Built on three pillars: metrics, logs, and traces.
Redis
An in-memory data store used as a cache, message broker, and database. Blazing fast because everything lives in RAM.
Memcached
A simple, high-performance distributed memory caching system. Stores key-value pairs in RAM. Simpler than Redis but less feature-rich.
Document Database
A NoSQL database that stores data as flexible JSON-like documents. MongoDB and CouchDB let each document have a different structure.
This page explains the idea. The "Time-Series Databases" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Time-Series Databases lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Time-Series Database in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
