Cloud Parts

Time Series Benchmark Suite (TSBS)

A Go toolkit that generates synthetic server-monitoring or IoT time series, bulk-loads it into a database and times a fixed set of time-series queries.

Time-series databasesRun by Tiger Data (formerly Timescale)License MITResults Source code

What it runs

TSBS is a set of Go programs. You pick a use case, a random seed, a scale (how many hosts or trucks), a time range and a reading interval, and tsbs_generate_data writes the data in the target database’s own load format. devops simulates 9 groups of server metrics, 100 values per host per reading; cpu-only keeps just 10 CPU metrics; iot simulates a fleet of trucks, with out-of-order and missing readings and late batches from trucks that were offline. The same seed gives every database identical data and identical queries. 4,000 hosts over three days at 10-second intervals is just over 100 million rows (1 billion metrics).

A run has three phases. First, data and queries are generated ahead of time, so generating them doesn’t slow the measurement. Second, tsbs_load (or a per-database tsbs_load_<db>) inserts the file with a chosen number of workers and batch size and reports metrics per second and rows per second. Third, tsbs_run_queries_<db> replays a file of one query type with N workers and reports minimum, median, mean, maximum and standard deviation of latency, plus wall-clock time. There are 15 devops query types (for example the max of one metric for 1 host over 1 hour, or the last reading of every host) and 12 IoT ones (last location, low fuel, driving sessions).

There is no official results page. Whoever wants numbers runs it on their own hardware with their own settings, and in practice that is usually a database vendor. The upstream repository has no releases or tags, and its last code change was in September 2023.

Setup

Use cases
devops (100 metrics per host per reading), cpu-only (10 CPU metrics), iot (trucks, with out-of-order and missing readings)
Dataset
Synthetic and deterministic from a seed; size set by host or truck count, time range and interval
Phases
Generate data and queries, bulk load, run queries; reads and writes are never measured together
Load metrics
Metrics per second and rows per second, for a chosen number of workers and batch size
Query metrics
Min, median, mean, max and standard deviation of latency per query type, and wall-clock time
Query types
15 for devops and cpu-only, 12 for IoT
Databases (upstream)
Akumuli, Cassandra, ClickHouse, CrateDB, InfluxDB 1.x, MongoDB, QuestDB, SiriDB, TimescaleDB, Amazon Timestream, VictoriaMetrics
Hardware
Not fixed: you choose the machines
Who publishes results
Whoever runs it, usually a database vendor
Maintenance
No releases; last code change September 2023, a CI update in May 2026; 121 open issues and pull requests (October 2026)

What the numbers don’t tell you

  • Vendors wrote it. InfluxData built the original to publish comparisons such as “InfluxDB is 27x Faster vs MongoDB for Time-Series Workloads”. Timescale forked it in 2018 and used it in its own posts. The data shape and query list follow the monitoring and IoT workloads those products target.
  • The data is synthetic: the generator inherited from influxdb-comparisons emits random walks per host at a fixed interval. Value distributions and regularity drive compression and query cost, so real data can behave quite differently.
  • Upstream code is old. It supports InfluxDB 1.x only; a pull request for InfluxDB 2.x has been open since July 2025, and InfluxDB 3 needs its own support (QuestDB’s fork added it). Tiger Data’s own TimescaleDB vs InfluxDB post compared TimescaleDB 1.7.1 with InfluxDB 1.8.0. Check the version and date behind any number you see.
  • Vendors keep their own forks. QuestDB’s fork adds loader optimisations for QuestDB, its own binary protocol and InfluxDB 2 and 3 support; TDengine and GreptimeDB keep copies too. Numbers produced by different forks aren’t comparable.
  • The results you find are vendor-run. QuestDB’s README, for example, shows QuestDB loading 8.59 million rows per second against 1.75 million for ClickHouse and 1.08 million for TimescaleDB on one r8a.8xlarge, all run by QuestDB in August 2026. Worker count, batch size and each database’s tuning flags (chunk size, partitioning, indexes) move such numbers a lot.
  • Loading and querying are measured separately; the README says concurrent inserts and queries aren’t tested, though that is how most monitoring systems run. The query set is mostly time-bucketed aggregates, threshold filters and last-point lookups.

Systems it covers that have a page here

Amazon TimestreamAWSAWS’s time-series databases: a serverless engine now closed to new customers, and managed InfluxDB 2 and 3.Apache CassandraOpen sourceA masterless, wide-column database that spreads and replicates partitions around a ring of equal nodes, with consistency chosen per request.ClickHouseOpen sourceAn open-source column-oriented database for real-time analytics, fast enough to serve dashboards over billions of rows.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.MongoDBCommercialA document database that stores JSON-like records with a flexible schema, from one replica set to a sharded cluster.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.TimescaleDBOpen sourceA PostgreSQL extension that turns ordinary tables into time-partitioned, compressed time-series tables.

In depth

The three phases#

Adapted from the README: generate three days of cpu-only data and one query type for 4,000 hosts, load it into TimescaleDB with 8 workers, then run the queries.

bash
# 1. Generate data and queries (same seed, scale and start time)
tsbs_generate_data --use-case=cpu-only --seed=123 --scale=4000 \
  --timestamp-start=2016-01-01T00:00:00Z --timestamp-end=2016-01-04T00:00:00Z \
  --log-interval=10s --format=timescaledb | gzip > /tmp/timescaledb-data.gz

tsbs_generate_queries --use-case=cpu-only --seed=123 --scale=4000 \
  --timestamp-start=2016-01-01T00:00:00Z --timestamp-end=2016-01-04T00:00:01Z \
  --queries=1000 --query-type=cpu-max-all-8 --format=timescaledb \
  | gzip > /tmp/timescaledb-cpu-max-all-8.gz

# 2. Load: prints metrics/s and rows/s
NUM_WORKERS=8 BATCH_SIZE=10000 BULK_DATA_DIR=/tmp scripts/load/load_timescaledb.sh

# 3. Run queries: prints min, median, mean, max latency and wall-clock time
gunzip < /tmp/timescaledb-cpu-max-all-8.gz | tsbs_run_queries_timescaledb --workers=8 \
  --postgres="host=localhost user=postgres sslmode=disable"

Forks and alternatives#

influxdb-comparisons

InfluxData, MIT

The original suite TSBS was forked from, focused on the devops use case. It still gets dependency updates.

questdb/tsbs

QuestDB fork

Actively maintained fork with QuestDB loader optimisations, its binary QWP protocol, query-generation fixes and InfluxDB 2 and 3 support.

taosdata/tsbs and GreptimeTeam/tsbs

vendor copies

TDengine’s copy adds a TDengine target for devops and IoT; GreptimeDB keeps a fork of the upstream repository.

SciTS

academic

Independent benchmark from a 2022 paper for scientific and industrial IoT workloads; tests inserts, queries and resource use on TimescaleDB, InfluxDB, PostgreSQL and ClickHouse.

ClickBench

analytics

Not a time-series benchmark: 43 analytical queries over one web-analytics table, with a public results page that time-series databases also appear on.

Sources · facts checked 2026-10-06

Improve this page on GitHub