Time-Series Databases in 2026 — TimescaleDB / InfluxDB 3 / QuestDB / ClickHouse / VictoriaMetrics Deep Dive

Prologue — "The era of one TSDB to rule them all is over"

Around 2017, if you said "time-series database," exactly one name came up: InfluxDB 1.x. By 2020 Prometheus had become the metrics standard, and TimescaleDB arrived on Postgres wielding SQL. By 2023 ClickHouse was eating into time-series territory from the OLAP side, and QuestDB shipped a Java engine optimised for fast ingest.

As of 2026, what we call "time-series data" actually contains at least four different workloads.

1. Metrics — periodic numbers like CPU, memory, QPS. Cardinality explosion is the main enemy.
2. Logs — one text line per timestamp + message. Full-text search plus time filtering.
3. Traces — distributed-system spans. A graph linked by span-id and trace-id.
4. IoT / sensor (telemetry) — device, vehicle, factory sensor series. Compression ratio and ingest throughput matter.

On top of those four axes are application categories like OLAP (analytical queries) and APM (application performance monitoring). So even though TimescaleDB, VictoriaMetrics, and ClickHouse all carry the "time-series DB" label, they target very different markets.

This post maps the nine major candidates as of May 2026 — TimescaleDB, InfluxDB 3 Core/Enterprise, QuestDB, ClickHouse, VictoriaMetrics, Prometheus + Grafana Mimir, M3DB, GreptimeDB, TDengine/OpenTSDB — covering position, strengths, and weaknesses. We close with "what should our team pick" answered across four domains: IoT, observability, finance, OLAP.

1. The 2026 TSDB Map — Metrics, Logs, Traces, IoT

The big picture first. The 2026 TSDB landscape sorts into three families.

By workload:

A core insight: attempts to unify on a single TSDB almost always fail. Cramming k8s observability and IoT into the same database breaks one side because the cardinality model is fundamentally different. Define your team's workload first, then pick the right tool.

2. TimescaleDB — Time Series on Top of Postgres

TimescaleDB is less a "time-series database" and more a time-series friendly Postgres extension. Since 2017 it has been the overwhelming #1 pick for teams who love SQL but want compression and partitioning automated.

Core concepts

• Hypertable — a table auto-partitioned by a time column. Users see it as a regular table.
• Chunk — a time chunk of a hypertable (e.g. 7-day windows). Old chunks can be compressed, moved, or deleted.
• Continuous Aggregate — a materialised view plus auto-refresh. Pre-aggregated results served fast.
• Compression — converts row-based storage to columnar then compresses (typically 90%+ savings).

Strengths

• Standard PostgreSQL — JOINs, windows, CTEs, foreign keys, JSON, geospatial all just work.
• Full-stack — handle relational and time-series data in a single database.
• Operations staff already know Postgres — same backup, replication, monitoring tools.
• Timescale Cloud (managed) is mature.

Weaknesses

• Heavier than Prometheus / VictoriaMetrics on the metrics-cardinality side.
• Past one million series, index cost climbs fast.
• Not as fast as ClickHouse for huge OLAP queries.

When to pick it

• Teams already on Postgres, with time series as a secondary workload.
• When SQL JOINs come up often (e.g. device metadata joined to sensor data).
• Cases where accuracy and transactions matter, like financial analytics.

-- Creating a TimescaleDB hypertable
CREATE TABLE metrics (
  time TIMESTAMPTZ NOT NULL,
  device_id TEXT NOT NULL,
  temperature DOUBLE PRECISION,
  humidity DOUBLE PRECISION
);

SELECT create_hypertable('metrics', 'time');

-- Automatic compression policy on time chunks
ALTER TABLE metrics SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'device_id'
);
SELECT add_compression_policy('metrics', INTERVAL '7 days');

-- Continuous aggregate
CREATE MATERIALIZED VIEW metrics_hourly
WITH (timescaledb.continuous) AS
SELECT
  time_bucket('1 hour', time) AS bucket,
  device_id,
  AVG(temperature) AS avg_temp,
  MAX(temperature) AS max_temp
FROM metrics
GROUP BY bucket, device_id;

3. InfluxDB 3 (DataFusion + Arrow) — A Completely Reborn InfluxDB

Going from InfluxDB 1.x → 2.x → 3.x, the internals were rewritten twice. The Flux language from 2.x is essentially deprecated, and 3.x is rebuilt on top of the Apache DataFusion query engine + Apache Arrow memory format + Apache Parquet storage. Practically, it is "an Arrow time-series database wearing the InfluxDB name."

Core changes

• Language — both InfluxQL and SQL are supported. Flux is effectively deprecated.
• Engine — the IOx engine, written in Rust, with DataFusion as the query planner.
• Storage — Parquet files on object storage (S3, GCS).
• Editions — Core (open-source, single node), Enterprise (cluster + HA), Cloud (managed, serverless).

Strengths

• Standard SQL — no more learning Flux or InfluxQL.
• Arrow Flight SQL for client communication — fast and standardised.
• Direct writes to object storage — practically unlimited retention, cheap.
• Excellent compression and ingest throughput for IoT workloads.

Weaknesses

• Migration path from 2.x to 3.x is not clean. If you run 2.x, expect pain.
• Cluster (Enterprise) is paid. The OSS story is weak at scale.
• Ecosystem feels fragmented compared with the Telegraf and Chronograf era.

When to pick it

• IoT or sensor data — hundreds of thousands of devices where compression is everything.
• If you already run InfluxDB 1.x or 2.x, as the migration target.
• When you want time series laid flat on object storage.

-- InfluxDB 3 SQL example (DataFusion)
SELECT
  date_bin('1 hour', time) AS hour,
  device_id,
  AVG(temperature) AS avg_temp
FROM metrics
WHERE time > now() - INTERVAL '7 days'
GROUP BY 1, 2
ORDER BY 1 DESC;

4. QuestDB — SQL Meets Fast Ingest

QuestDB is a Java-written time-series-focused column store. The headline pitch is "it speaks the Postgres wire protocol and the InfluxDB Line Protocol at the same time." Meaning you can write SQL and ingest with InfluxDB-compatible clients.

Core concepts

• SYMBOL type — stores repeating strings via dictionary encoding. Effective for cardinality control.
• PARTITION BY — partition by DAY, MONTH, or HOUR. Old partitions can be auto-dropped via retention.
• DEDUP — automatic deduplication on identical timestamp + key.
• ILP (InfluxDB Line Protocol) — line-by-line ingest over TCP or HTTP.

Strengths

• Very high ingest throughput — millions of rows per second on a single node.
• SQL is near-standard — any client speaking PG wire connects straight in.
• Fast time-series JOINs — deep support for ASOF JOIN (closest time).
• Strong reputation in financial tick-data circles.

Weaknesses

• Cluster (distributed) is Enterprise-only. OSS is single-node.
• Smaller ecosystem — fewer ops tools, fewer examples, fewer SIs than other candidates.
• Not suitable for general (transactional) data.

When to pick it

• Financial market data (ticks) — when fast ASOF JOIN and precision are required.
• When a single node needs to absorb extreme ingest throughput.
• When you want SQL plus InfluxDB-client compatibility.

-- QuestDB ASOF JOIN — a time-series superpower
SELECT
  trades.timestamp,
  trades.symbol,
  trades.price,
  quotes.bid,
  quotes.ask
FROM trades
ASOF JOIN quotes
WHERE trades.symbol = quotes.symbol
  AND trades.timestamp > '2026-01-01';

5. ClickHouse — A Column Store with Crushing Performance

Strictly, ClickHouse is not a time-series database — it is an OLAP column store. But if you sort and partition by a time column, you can use it as a TSDB, and it will deliver analytical performance that outclasses other TSDBs. Between 2024 and 2026 it became one of the most adopted observability backends.

Core concepts

• MergeTree engine family — sort with ORDER BY, partition with PARTITION BY. ReplicatedMergeTree handles replication.
• Column compression — choose from codecs like LZ4 (default), ZSTD, Delta, DoubleDelta, Gorilla.
• Materialized View — trigger-based pre-aggregation, similar to continuous aggregates.
• Projection — store the same data in another sort order to speed alternate query patterns.

Strengths

• Analytical query speed is exceptional — top tier even among OLAP databases.
• Rich codecs — time-series-specific compression like Gorilla (for floats) and DoubleDelta (for time).
• Practically every I/O option — JDBC, ODBC, HTTP, Kafka integration, Parquet external tables.
• Runs well even on tens to hundreds of TB.

Weaknesses

• Weak at point UPDATE and DELETE (batch merge model). Not for transactional workloads.
• Operations are complex — learning merges, replication, and ZooKeeper (or ClickHouse Keeper).
• Cardinality management is less automated than InfluxDB or VictoriaMetrics for pure metrics.

When to pick it

• An OpenTelemetry backend — unified storage for OTel traces, logs, and metrics.
• Large-scale log analysis.
• BI plus time-series fusion (analysts query freely in SQL).
• A unified data warehouse for user-behaviour events plus time series.

-- ClickHouse: time series with Gorilla compression
CREATE TABLE metrics (
  time DateTime64(3, 'UTC') CODEC(DoubleDelta, ZSTD),
  device_id LowCardinality(String),
  metric LowCardinality(String),
  value Float64 CODEC(Gorilla, LZ4)
) ENGINE = MergeTree
PARTITION BY toYYYYMM(time)
ORDER BY (device_id, metric, time);

-- Pre-aggregated materialized view
CREATE MATERIALIZED VIEW metrics_hourly
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMM(hour) ORDER BY (device_id, metric, hour) AS
SELECT
  toStartOfHour(time) AS hour,
  device_id,
  metric,
  avgState(value) AS avg_v,
  maxState(value) AS max_v
FROM metrics GROUP BY hour, device_id, metric;

6. VictoriaMetrics — Prometheus-Compatible and Lean

VictoriaMetrics (VM) in one sentence: "Prometheus-compatible, but faster, leaner, and more disk-efficient." It speaks PromQL nearly identically to Prometheus, and adds MetricsQL on top. Growing steadily since 2020, by 2026 it is one of the standard options for large metrics backends.

Core concepts

• vmstorage / vmselect / vminsert — split-responsibility components in cluster mode.
• vmagent — a drop-in for Prometheus scraping, also handles remote_write.
• vmalert — Prometheus-compatible alerting rules.
• MetricsQL — a PromQL superset with extensions like rollup functions and improved histogram quantiles.

Strengths

• Prometheus-compatible — keep your Grafana dashboards and alerting rules.
• Small disk footprint — 7x or better savings vs Prometheus is common.
• Operationally simple — clear single-binary OSS and cluster options.
• Strong cardinality-visibility tooling (cardinality explorer).

Weaknesses

• Beyond "Prometheus, but lighter," differentiation is thin. If that value isn't clear, why bother?
• Logs and traces are separate (VictoriaLogs, VictoriaTraces). Not an integrated solution.
• The distributed cluster still requires attention to operate.

When to pick it

• You already use Prometheus and hit retention or cardinality limits.
• A single node receiving heavy metrics load.
• When cardinality visibility is required.

# vmagent as a Prometheus scrape replacement
vmagent \
  -promscrape.config=/etc/scrape_config.yml \
  -remoteWrite.url=http://vmstorage:8480/insert/0/prometheus/

# PromQL as-is
sum(rate(http_requests_total[5m])) by (service)

# MetricsQL extension
rollup_rate(http_requests_total[5m]:1m)

7. Prometheus + Mimir — The Standard for Kubernetes Metrics

In 2026 Prometheus is still the de-facto standard for Kubernetes metrics. A CNCF Graduated project that runs everywhere. Its limits are clear — long-term retention and horizontal scaling. The most common solution to both is Grafana Mimir (the successor to Cortex).

Where Prometheus sits

• Pull-based metrics — periodic scraping of /metrics endpoints.
• PromQL — the de-facto metrics query language.
• Local on-disk TSDB. Typically about 15 days of retention.

What Mimir solves

• Long-term retention — accumulate flat in object storage (S3/GCS). One year or more becomes normal.
• Horizontal scaling — components split into distributor / ingester / store-gateway / querier and more.
• Multi-tenancy — isolate metrics for several teams in one cluster.
• Global view — query many Prometheus instances as one.

Competitors

Strengths and weaknesses

Strengths: perfect integration with Kubernetes and the CNCF ecosystem, a deep exporter library, standard PromQL. Weaknesses: anything beyond metrics (logs, traces) is a separate stack, and a cardinality explosion makes operations heavy.

When to pick it

• When Kubernetes infrastructure or application metrics are the main workload.
• A team already standardised on PromQL and Grafana.
• Building a multi-tenant observability platform (choose Mimir).

8. GreptimeDB — The Rust Newcomer

GreptimeDB is a Rust-based TSDB launched in 2022 that grew fast between 2024 and 2026. Its ambition is bold — metrics, logs, and traces in a single database, cloud-native.

Highlights

• Written in Rust — memory safety and performance.
• SQL + PromQL + InfluxQL all supported — migration-friendly.
• Local + object storage split — compute and storage separated, writes directly to S3.
• OpenTelemetry-native — OTLP reception as a first-class citizen.

Strengths

• Metrics, logs, and traces in one DB — attractive as a unified observability solution.
• Object-storage split — cheap long-term retention.
• Active OSS community, with a managed cloud option.

Weaknesses

• Maturity is not yet as battle-tested as Prometheus or ClickHouse.
• A smaller pool of operational experience.
• Fewer large-scale production references.

When to pick it

• Building a new observability stack from scratch.
• When unified OTel-aligned metrics, logs, and traces are the goal.
• When you prefer Rust-based leanness and simplicity.

9. M3DB / TDengine / OpenTSDB — Other Candidates

M3DB

• A distributed TSDB built and open-sourced by Uber.
• Splits metrics, indexing, and aggregation components.
• Proven at Uber's scale (hundreds of millions of series).
• Weakness: external adoption is narrow, operations are complex.

TDengine

• An IoT-focused TSDB from China's Taos Data.
• A one-table-per-device model — efficient for IoT cardinality.
• Custom SQL with cluster options.
• Weakness: small English-speaking community, with some features paywalled in Enterprise.

OpenTSDB

• A first-generation TSDB that put a time-series index on top of HBase.
• Stable, but the ecosystem is stagnant.
• Rarely chosen for new projects.

Apache Druid / Pinot

• Not strictly TSDBs but frequent participants in OLAP with a strong time dimension.
• Strong in real-time dashboards and event analytics.
• Heavy as a pure metrics backend.

10. Compression Strategy — Gorilla, ZSTD, Snappy

In TSDBs, disk usage equals cost. So every major TSDB in 2026 combines multiple codecs.

Time-series-specific codecs

• Gorilla (Facebook) — specialised for floating-point series. XOR plus variable-length encoding averages about 1.37 bytes per point.
• Delta encoding — store only differences between adjacent integers. Especially good for timestamps.
• DoubleDelta — the delta of deltas. Highly effective on near-constant intervals like time columns.
• RLE (Run-Length Encoding) — compresses runs of the same value.
• Dictionary encoding — strings to IDs (QuestDB SYMBOL, ClickHouse LowCardinality, Parquet dictionary).

General-purpose codecs (applied after the above)

• LZ4 — fastest, moderate ratio. Good for hot data.
• Snappy — Google's, similar position to LZ4.
• ZSTD — Facebook's, excellent balance of ratio and speed. Common for cold data.
• gzip — older standard. Decent ratio, slower.

Combination pattern

Most TSDBs pipeline "time-series codec → general-purpose codec". For example in ClickHouse:

• Time column: DoubleDelta + ZSTD
• Measurement (float): Gorilla + LZ4
• Category strings: LowCardinality + ZSTD

This combo typically compresses 5-20x versus raw. Disk costs drop below 1/10.

11. Cardinality Explosion — The TSDB's Number-One Enemy

"Cardinality" is the TSDB metric that explodes most often. The definition is simple — the number of unique time series.

What blows up cardinality

Each series is usually defined like this.

metric_name{label1=value1, label2=value2, ...}

The number of label-value combinations is the number of series. Dangerous labels include:

• User ID — one million users multiplies series by one million.
• Request ID, session ID, trace ID — practically unbounded.
• IP address — dynamic IPs explode.
• URL path with parameters — /user/12345/order/67890.
• Raw error message — variable parts explode it.

What happens when it explodes

• Indexes no longer fit in memory and queries crawl.
• Disk usage skyrockets.
• Ingest slows and metrics drop.
• Grafana dashboards time out.

How to fix it

1. Label hygiene — identify exploding labels and remove them from metrics, or push them to traces and logs.
2. Cardinality visibility — VictoriaMetrics vmui cardinality explorer, Prometheus cardinality queries, Grafana Mimir analysis.
3. Cardinality limits — enforce per-series label-value limits at the ingest side.
4. Drop / Rewrite rules — strip dangerous labels at scrape time.
5. Sampling and aggregation — do not store every series; keep key aggregates.

The "send it to traces" rule

High-cardinality dimensions (user, request ID, trace ID) belong in traces, not metrics. That is the standard 2026 answer. Metrics are for aggregates, traces are for detail.

12. Standards — Prometheus Exposition, OpenMetrics, OTel

Even with different TSDBs, the standards used to push data into them are converging.

Prometheus exposition format

# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 1234 1715814000000
http_requests_total{method="POST",status="201"} 56 1715814000000

• The most universal. Every TSDB accepts or converts it.
• Four types: counter, gauge, histogram, summary.

OpenMetrics

• The IETF-standardised version of the Prometheus format.
• Supports ExemplarLink for linking to traces.
• Compatible with the Prometheus format by default.

OpenTelemetry (OTel)

• A unified standard for metrics, logs, and traces.
• Sent via the OTLP protocol to a collector or directly to a backend.
• The de-facto multi-signal standard in 2026.

InfluxDB Line Protocol

measurement,tag1=value1 field1=1.0 1715814000000000000

• Accepted by InfluxDB, QuestDB, and some IoT backends.
• Often used as a lightweight option in IoT gateways.

Recommended approach

For a new project, treat OTel (OTLP) as the first-class signal, then accept the Prometheus format or OTLP directly depending on the backend. All major TSDBs support both.

13. IoT vs APM vs Finance — Who Should Pick What

Bringing it together. Recommendations by domain as of May 2026.

Kubernetes / observability (metrics-led)

• First pick: Prometheus + Grafana Mimir (or VictoriaMetrics cluster).
• Why: standard PromQL, rich ecosystem, mature cardinality tooling.
• If you also need traces/logs: add Tempo + Loki, or integrate via ClickHouse.

Multi-signal observability (metrics + logs + traces unified)

• First pick: ClickHouse (as the OTel backend) or GreptimeDB.
• Why: all three signals in one DB queried with SQL, with columnar compression for cost.
• Downside: operational burden is higher than Prometheus.

IoT / sensors (tens to hundreds of thousands of devices)

• First pick: InfluxDB 3 or TDengine or TimescaleDB.
• Why: compression ratio, ingest throughput, downsampling, edge integration.
• Selection criteria: extreme ingest → TDengine or QuestDB; SQL plus general data → TimescaleDB; object-storage integration → InfluxDB 3.

Financial market data (ticks, quotes)

• First pick: QuestDB or ClickHouse or kdb+.
• Why: nanosecond timestamps, ASOF JOIN, fast time-series analytics.
• Where kdb+ sits: still the top pick for some hedge funds. Cost and the talent pool are the barriers.

General OLAP + time series

• First pick: ClickHouse or TimescaleDB.
• Why: BI plus time series joined in SQL.
• Selection criteria: heavy on transactional and relational fusion → TimescaleDB; heavy on large analytical queries → ClickHouse.

Seven anti-patterns

1. "One TSDB to rule them all" — without separating workloads, the cardinality model breaks.
2. Stuffing user ID or request ID into metric labels — cardinality explosion.
3. Sticking with default compression codecs — picking per column trait can yield 5x differences.
4. No retention policy, infinite accumulation — disk cost runs away within a year.
5. Skipping continuous aggregates — aggregating from raw every time.
6. Keeping more than a year with bare Prometheus — pick one of Mimir, VictoriaMetrics, or Thanos.
7. Mixing metric and trace responsibilities — detail goes to traces, aggregates to metrics.

What comes next

• Candidate follow-ups: OpenTelemetry deep dive — Collector, Processor, and Exporter in practice, a Grafana dashboard design guide, cardinality-explosion case studies and operating patterns.

"Time series is not a single workload. Metrics, logs, traces, and IoT may look alike but they are different problems. The right answer is to use different tools."

— Time-Series Databases 2026, end.

References

• TimescaleDB Documentation
• TimescaleDB GitHub — timescale/timescaledb
• InfluxDB 3 Documentation
• InfluxDB 3 Core/Enterprise — InfluxData
• InfluxDB IOx — GitHub
• Apache DataFusion
• Apache Arrow
• QuestDB Documentation
• QuestDB GitHub — questdb/questdb
• ClickHouse Documentation
• ClickHouse GitHub — ClickHouse/ClickHouse
• ClickHouse Codecs
• VictoriaMetrics Documentation
• VictoriaMetrics GitHub — VictoriaMetrics/VictoriaMetrics
• Prometheus Documentation
• Grafana Mimir
• Grafana Mimir GitHub — grafana/mimir
• Thanos — long-term Prometheus
• GreptimeDB
• GreptimeDB GitHub — GreptimeTeam/greptimedb
• M3DB GitHub — m3db/m3
• TDengine GitHub — taosdata/TDengine
• OpenTSDB
• Apache Druid
• Apache Pinot
• OpenMetrics specification
• OpenTelemetry specification
• Gorilla — Facebook in-memory TSDB paper
• Facebook ZSTD
• Snappy compressor
• Prometheus high-cardinality guidance