Time-Series Databases

A time-series database is designed for data that changes over time. Every data point is associated with a timestamp, and new data usually arrives continuously.

Examples include sensor readings, application metrics, stock prices, server logs, and request latency. Although this data can be stored in a general-purpose database, its scale and access patterns create challenges that a time-series database is specifically designed to solve.

Key Terms to Talk About

Timestamp · Series · Tags · High-cardinality data · Ingestion rate · Time partitioning · Compression · Downsampling · Retention policy · Out-of-order data

1. Properties of a time-series database

Time-series workloads have a few important properties:

• Every sample has a timestamp. Time is a fundamental part of the data model, not simply another column.
• Data arrives continuously. New samples are appended every second, millisecond, or even more frequently.
• Write volume is high. A system may need to ingest millions or billions of samples within a short period.
• Queries are time-based. Most queries retrieve data for a particular time range, such as the last hour, day, or month.
• Recent data is queried more frequently. Older data may be compressed, aggregated, or deleted according to a retention policy.
• Samples may arrive late or out of order. Network delays and disconnected devices can cause older samples to reach the database after newer ones.
• Data is commonly aggregated. Users often need minimums, maximums, averages, percentiles, or counts rather than individual samples.

These properties influence how the database ingests, stores, indexes, and queries its data.

2. Let us talk about data volume

Consider a system collecting sensor data. Suppose 100,000 sensors each send one sample every second.

The number of samples arriving in one day is:

100,000 samples/second × 60 seconds × 60 minutes × 24 hours
= 8,640,000,000 samples/day

That is 8.64 billion samples to ingest in a single day.

Over 30 days, the system would receive:

8.64 billion × 30
= 259.2 billion samples

This calculation counts only the number of samples. Each sample may also contain a timestamp, a value, a sensor identifier, and tags such as location or sensor type. Replication and database indexes increase the required storage further.

The database must not only ingest this volume. It must also allow users to query it efficiently. A request such as “show the average temperature for every factory during the last 24 hours” may need to process billions of underlying samples.

At this scale, writing and querying samples one row at a time becomes expensive. A time-series database therefore relies on batching, partitioning, compression, and precomputed aggregates.

3. Storage design: series order, updates, and out-of-order data

Time-series data is usually stored in series order. A series represents all samples belonging to the same measurement and the same set of identifying tags.

For example:

measurement: temperature
sensor_id:   sensor-42
location:    factory-a

All temperature readings from sensor-42 in factory-a belong to one series. Within that series, samples are organized by timestamp.

Storing nearby timestamps together has several benefits:

• New samples can usually be appended sequentially.
• A time-range query can read only the relevant blocks.
• Similar timestamps and values can be compressed efficiently.
• Old time partitions can be aggregated or deleted as a unit.

The ideal write path is append-only, but real systems must also handle updates and out-of-order samples. A sensor may lose its network connection, buffer readings locally, and upload them later. A corrected reading may also replace a previously stored value.

To support these cases, the database can first write incoming samples to an in-memory buffer and a durable write-ahead log. The buffer sorts samples before writing them into immutable time-based blocks. Late samples can be written into a small correction block and merged with the original block later.

This approach keeps the normal ingestion path fast while still allowing delayed or corrected data. However, frequent updates to old data are expensive because compressed, immutable blocks may need to be rewritten. Time-series databases work best when updates are the exception rather than the primary workload.

4. Timestamp and tags define uniqueness

A timestamp tells us when a sample was recorded, but it does not tell us which series produced it. Many sensors can generate a reading at exactly the same time.

Tags identify the series:

measurement: temperature
tags:
  sensor_id: sensor-42
  location: factory-a
timestamp:   2026-07-23T10:31:00Z
value:       72.4

The unique identity of this data point is therefore the combination of:

measurement + tag set + timestamp

In this example, the measurement and tags identify the series, while the timestamp identifies a particular point within that series.

Tags also help the database cluster and locate related data. A query can select a time range and then filter or group samples by tags:

Find the average temperature
between 10:00 and 11:00
grouped by location

The database first identifies matching series using the tags and then reads the relevant timestamp range from those series.

Tag design needs care. Stable, reusable values such as location, sensor_type, or region work well. Values that are different for almost every sample, such as request_id, can create an extremely large number of series. This is called high cardinality, and it can make the series index expensive to store and search.

Bringing it together

A time-series database is built around four connected ideas:

1. The workload is continuous, timestamped, and mostly append-only.
2. Even a simple sensor system can generate billions of samples per day.
3. Data must be stored in series and time order while still accommodating late or corrected samples.
4. A data point is uniquely located by its measurement, tags, and timestamp.

In a system design interview, begin with the expected ingestion rate and retention period. Then explain how series-based storage, time partitioning, batching, compression, and tag indexes allow the system to ingest and query that volume efficiently.