cloudparts

OpenTSDBArchived

A time-series database built on HBase: stateless Java daemons that turn metric, timestamp, value and tags into compact HBase rows, one row per series per hour.

What it is
Time-series databases
Used for
Metrics
Type
Open source
Made by
OpenTSDB project (started at StumbleUpon)
License
LGPL-2.1-or-later and GPL-3.0-or-later
Status
Archived since 12 December 2024
Facts checked
23 October 2026
Website Source code (archived)

What it is

OpenTSDB is a set of Time Series Daemons (TSDs) in front of HBase. Each TSD is independent, with no master and no shared state, so you scale reads and writes by adding TSDs, and clients never talk to HBase directly. A data point is a metric name, a timestamp in seconds or milliseconds, an integer or float value, and at least one tag such as host=web01. You write with a telnet-style put line or a JSON POST to /api/put, and query over HTTP with an aggregator, an optional downsampler and tag filters. The README promises that OpenTSDB never deletes or downsamples stored data.

Storage is what made it scale. Metric names, tag keys and tag values are mapped to 3-byte ids in a separate tsdb-uid table. A row key is the metric id, the timestamp rounded down to the hour and the sorted tag ids, optionally prefixed by a salt byte (since 2.2) to spread writes across regions; each point in that hour is a column named by its offset. Version 2.3 added Google Cloud Bigtable as a backend and an experimental Cassandra shim, and 2.4 (2018) added rollups, pre-aggregates and histograms. Grafana still ships an OpenTSDB data source for versions 2.1 to 2.4, and Telegraf can write to it. The project has not had a stable release since 2.4.1 (2021) and no commits since December 2024.

Why teams pick it

  • Scales writes with HBase: TSDs are stateless, and salting spreads a hot metric across regions
  • Keeps every raw point at full resolution, with no forced downsampling or expiry
  • Simple ingestion: one put line per point over TCP, or batches of JSON over HTTP
  • Supported by existing tools, including Grafana’s built-in data source and Telegraf’s output

Watch out for

  • Unmaintained: no stable release since 2.4.1 (September 2021) and no commits since December 2024
  • Known remote-code-execution bugs in 2.4.1 (CVE-2023-25826, CVE-2023-36812) are fixed only in the 2.5.0 release candidate, and new reports from October 2026 are unanswered; never expose a TSD to untrusted networks
  • Needs a running HBase cluster (HDFS and ZooKeeper included) or Google Cloud Bigtable; the Cassandra shim is experimental and needs the ByteOrderedPartitioner
  • Few tags per point (8 by default) and no SQL: queries are limited to aggregators, downsamplers and tag filters

Specs

Compare with alternatives →
Data model
Points of metric, timestamp, value and tags; one HBase row per series per hour
Query language
HTTP API with aggregators, downsamplers and tag filters; no SQL
Client protocol
Telnet-style put lines or JSON over HTTP
How it scales
Stateless TSDs in front of HBase; salting spreads hot metrics over regions
Storage engine
HBase, or Google Cloud Bigtable
Retention
Never deletes or downsamples stored data
Written in
Java
Ways to run it
Self-hosted; the project is archived

Alternatives, recommended first

What all time-series databases have in common →Compare side by side →
InfluxDBOpen sourceThe best-known time-series database, fed by line protocol and Telegraf; now in its third generation, a Rust rewrite that keeps data as Parquet files on object storage.PrometheusOpen sourceThe standard open-source metrics system: it pulls numbers from your services over HTTP, stores them as labelled time series and alerts on PromQL queries.TimescaleDBOpen sourceA PostgreSQL extension that turns ordinary tables into time-partitioned, compressed time-series tables.QuestDBOpen sourceA columnar time-series database in Java, C++ and Rust that ingests millions of rows a second and answers time-series SQL, with old partitions kept as Parquet.KairosDBOpen sourceA Java time-series server that stores metrics with tags in Apache Cassandra; it began in 2013 as a rewrite of OpenTSDB and is now kept going by a single maintainer.

How it fits with other technologies

Write a point two ways, then query a downsampled sum · bash

# Telnet-style: one point per line
echo "put sys.cpu.user 1356998400 42.5 host=webserver01 cpu=0" | nc localhost 4242

# HTTP: several points per request
curl -X POST http://localhost:4242/api/put -d '[
  {"metric": "sys.cpu.user", "timestamp": 1356998400, "value": 42.5,
   "tags": {"host": "webserver01", "cpu": "0"}}
]'

# Sum across all hosts and CPUs, as 1-minute averages, for the last hour
curl 'http://localhost:4242/api/query?start=1h-ago&m=sum:1m-avg:sys.cpu.user'

See it in a real stack

No architecture uses OpenTSDB yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2010–2024

Benoît Sigoure wrote OpenTSDB at StumbleUpon in 2010 to keep the metrics of the company’s systems, which ran to over a billion data points a day. HBase, the Bigtable-style store from the Hadoop world, already handled huge sorted tables, so OpenTSDB became a thin layer of daemons that encoded points into compact HBase rows. StumbleUpon also released tcollector, a Python framework that gathers Linux, MySQL, HBase and other metrics and sends them to a TSD.

Version 1.0 was tagged in December 2011 and 2.0 in May 2014, adding the HTTP API and annotations. Later 2.x releases added salting, Bigtable and Cassandra backends, expressions, rollups and histograms; Yahoo later took over maintenance, together with the community. After 2.4.0 in December 2018, releases slowed: 2.4.1 in September 2021, then a 2.5.0 release candidate in December 2024 with security fixes. Work on a separate 3.0 branch stopped receiving commits in 2023.

Why it’s built this way

Store data in HBase instead of writing a storage engine
HBase already split sorted tables into regions across many servers, so OpenTSDB only had to design row keys; it inherits HBase’s scale and its operating cost.
Short numeric ids for names and tags
Repeating long metric and tag strings in every row key would waste space; 3-byte ids keep row keys small and keep a series’ rows sorted together.
One row per series per hour
Points for the same series and hour sit in one row, so a time-range query becomes a short scan of adjacent rows.

Timeline

  1. 2010

    Benoît Sigoure starts OpenTSDB at StumbleUpon

  2. 2011

    Version 1.0 is tagged in December

  3. 2014

    OpenTSDB 2.0 adds the HTTP API

  4. 2018

    2.4.0 adds rollups and histograms

  5. 2021

    2.4.1, the last stable release

  6. 2023

    Remote-code-execution flaws in 2.4.1 are published as CVEs

  7. 2024

    A 2.5.0 release candidate in December, then no further commits

Sources13 · facts checked 23 October 2026

Improve this page on GitHub