Understanding Time Series Databases: Features, Popular Options, and How to Choose

Time Series Database Overview

The article, originally from the ADDOPS team, notes that time‑series databases (TSDB) have become a hot topic due to growing log and container monitoring demands, and serves as a concise introduction before deeper Prometheus analyses.

1. What is a Time Series Database?

A TSDB is a specialized database that stores time‑series data—records that include a timestamp field, such as stock prices, temperature readings, or CPU usage. Queries always filter by a time range and return timestamps alongside the values.

The simplest definition is any data format that contains a timestamp field; virtually all data can be given a timestamp.

Time‑series data is visualized with time on the horizontal axis. Its main characteristics are:

Simple data structure

Large data volume

According to Baron Schwartz, typical TSDB workloads involve:

Over 90% of work is high‑frequency, high‑capacity writes

Writes are appended over time (e.g., per second or minute)

Writes are I/O‑bound

Updates to single points are rare

Deletions usually span large time ranges (days, months, years)

Queries are ordered by time or another function and often executed in parallel

TSDBs are already used in automation, oil, chemical industries, and many enterprises store monitoring data in TSDBs for analysis and alerting.

2. Common TSDBs

Ranking of TSDBs in DB‑engines:

InfluxDB

Written in Go, InfluxDB is currently the most popular TSDB. It offers a SQL‑like query language, rich data types, and full‑event storage. However, its cluster mode is closed‑source, and HA is provided via a less‑elegant relay tool. Its design favors consistency (CP).

OpenTSDB

Implemented in Java, OpenTSDB stores data in HBase or Cassandra, making it a natural extension for environments already using the HBase ecosystem.

Prometheus

Developed by SoundCloud in 2012 and now a CNCF project, Prometheus excels at container monitoring. It stores data in memory with periodic disk flushes, uses a custom float64 metric type, and provides the powerful PromQL query language. Its design prioritizes performance and alert timeliness (AP) over strong consistency.

Beringei

Facebook’s open‑source TSDB, based on the Gorilla paper, adds sharding to avoid single‑point failures, offering a design similar to Prometheus but with higher availability.

Some Thoughts

Choosing a TSDB involves trade‑offs governed by the CAP principle. If strong consistency and no data loss are essential, select a TSDB that emphasizes consistency, accepting lower performance and higher maintenance effort. If occasional data loss is acceptable in exchange for fast, real‑time queries and alerting, prioritize performance‑oriented solutions. Ultimately, there is no universal “silver bullet.”