TimescaleDB vs InfluxDB 2026

The time-series database category has fractured into clearer roles in 2026. Metrics workloads (Prometheus-shaped, Grafana-fronted) and IoT workloads (device telemetry, sensor streams) and observability traces (OpenTelemetry) have ended up with different default databases. The five real choices — TimescaleDB, InfluxDB 3.0, QuestDB, Apache IoTDB, and VictoriaMetrics — each fit a specific shape. This post separates the categories and tells you which one to pick for each.

What changed in 2024-2025#

Three things meaningfully shifted the comparison:

InfluxDB 3.0 shipped on Apache Arrow and DataFusion, with the FDAP architecture (Flight, DataFusion, Arrow, Parquet). InfluxDB became, architecturally, a different database — closer to a lakehouse than the LSM-tree storage of InfluxDB 1.x and 2.x. Better high-cardinality handling, SQL support added alongside InfluxQL and Flux.
Timescale Cloud stabilized as a managed Postgres-with-time-series offering. Hypercore (the combined row-store and columnstore engine) shipped, closing the cardinality and compression gap with purpose-built TSDBs.
VictoriaMetrics and Apache IoTDB matured into clearly differentiated choices — VictoriaMetrics for Prometheus-compatible metrics at scale, IoTDB for industrial IoT at very high ingest rates.

The “one time-series database for everything” framing died. Pick by workload.

The five choices, by workload#

Metrics: VictoriaMetrics (and Prometheus)#

For Prometheus-shaped metrics (counters, gauges, histograms, scraped from exporters), VictoriaMetrics is the production answer for anything past a single Prometheus instance. PromQL-compatible, Prometheus remote-write compatible, cluster mode for horizontal scale.

What we deploy:

VictoriaMetrics single-node for small workloads (under a few million active series). Replaces a single Prometheus with longer retention and better compression.
VictoriaMetrics cluster for medium and large workloads. vmselect, vminsert, vmstorage. Easier to operate than Cortex or Thanos for most teams.
VictoriaLogs for logs in the same operational model.

Cost: dramatically lower than Datadog or New Relic for metrics. Operations: lighter than Cortex, similar to Mimir but with simpler architecture.

IoT and industrial telemetry: Apache IoTDB or QuestDB#

For high-ingest sensor workloads — millions of samples per second from industrial equipment, vehicles, smart meters — Apache IoTDB and QuestDB are the serious choices.

Apache IoTDB has the heritage at very high ingest rates (industrial automation, Siemens-scale deployments). TsFile native format, tree-structured schema that fits IoT device hierarchies well. Strong cluster mode.

QuestDB is the C++ time-series engine focused on financial market data and high-rate telemetry. InfluxDB-line-protocol-compatible ingest, Postgres-wire-protocol queries, SQL with time-series extensions. We have shipped this for trading and IoT analytics at clients hitting millions of inserts per second on small clusters.

For most IoT workloads in 2026 we pick QuestDB unless the team is already deep in Apache IoTDB tooling.

General time-series alongside relational: TimescaleDB#

For teams who want time-series and relational data in the same database — operational telemetry alongside customer records, IoT readings alongside device metadata, financial ticks alongside order books — TimescaleDB on Postgres is the right answer.

What you get:

Hypertables — automatically partitioned time-series tables.
Continuous aggregates — materialized rollups that update incrementally.
Hypercore — Timescale’s combined row-store plus columnstore engine that gives both fast inserts and fast analytical queries on older data.
Every Postgres extension (pgvector, PostGIS, pg_partman) works alongside.

Timescale Cloud is the managed offering on AWS. Self-hosted on Postgres is supported. The Apache 2.0 vs TSL split for some advanced features has been mostly settled, but read the license terms before assuming everything is free.

Time-series database categories

General time-series at very high cardinality: InfluxDB 3.0#

InfluxDB 3.0’s Apache Arrow architecture handles high-cardinality (millions of unique time-series tag combinations) better than the older versions ever did. The trade-off is that the operational story is different — closer to a Parquet-on-object-storage system than a traditional database.

What InfluxDB 3.0 does well:

High-cardinality metrics without the brutal RAM scaling that hit InfluxDB 1.x and 2.x.
SQL on time-series data alongside InfluxQL and Flux.
Cloud-native architecture that scales storage and compute independently.
InfluxDB Cloud as the managed offering.

What we still watch for:

The migration path from InfluxDB 2.x to 3.0 is non-trivial. Many existing InfluxDB users have not moved yet.
Self-hosted InfluxDB 3.0 (Open Source Edition) is younger than the cloud product.
Tooling around InfluxDB 3.0 is catching up to the architecture.

For teams with an existing InfluxDB investment and high-cardinality pain, 3.0 is the right migration target. For greenfield workloads, we more often pick TimescaleDB or QuestDB depending on the shape.

Observability traces: not these databases#

For OpenTelemetry-shaped traces, we no longer recommend a generic time-series database. The category has moved to purpose-built trace stores (Jaeger backends, Tempo, Honeycomb, ClickHouse-based stores like SigNoz). Time-series databases are for metrics, IoT, and analytical time-series — not for distributed traces.

Retention and downsampling patterns#

The recurring time-series ops question: how do you keep useful data forever without paying for storage forever?

The pattern across all five databases:

Raw data retained for a short hot window (7 to 30 days).
5-minute or 1-minute aggregates retained for a medium window (months to a year).
Hourly or daily aggregates retained indefinitely.

Implementation per database:

TimescaleDB: Continuous aggregates plus data retention policies. Continuous aggregates are real materialized views that update incrementally.
InfluxDB: Downsampling tasks (Flux-based or SQL-based in 3.0) plus retention policies.
VictoriaMetrics: Recording rules or per-tenant retention. Streaming downsampling via vmagent.
QuestDB: SAMPLE BY queries to generate aggregates; partition-based retention.
Apache IoTDB: TTL on storage groups, continuous queries for downsampling.

The hard part is not the technical capability — all five do this. The hard part is deciding which aggregates matter and getting the cardinality right so the aggregates do not themselves explode in size.

Retention pyramid

When to pick each, in plain terms#

Prometheus-shaped metrics → VictoriaMetrics.
General time-series alongside relational data → TimescaleDB on Postgres.
High-cardinality time-series at scale → InfluxDB 3.0 (especially if you already have InfluxDB) or Timescale with Hypercore.
High-ingest IoT and industrial telemetry → QuestDB or Apache IoTDB.
Financial market data → QuestDB (low-latency ingest) or KDB+ (if budget allows).
OpenTelemetry traces → purpose-built trace store, not a generic TSDB.

The cost story#

VictoriaMetrics self-hosted is dramatically cheaper than Datadog or New Relic for metrics at any scale beyond hobby projects.

Timescale Cloud and InfluxDB Cloud are roughly comparable at small to medium scale, with Timescale tending cheaper for hybrid workloads (time-series plus relational).

QuestDB self-hosted is light operationally and cheap on infrastructure. QuestDB Cloud is available for teams who want managed.

Apache IoTDB is open-source heavy-lifting — cheap on licenses, real on engineering.

Where pdpspectra fits#

We have shipped VictoriaMetrics replacing a sprawling Prometheus-plus-Thanos setup at a healthcare client, TimescaleDB for a logistics platform that wanted IoT readings next to operational data, QuestDB for an industrial telemetry workload at millions of samples per second, and InfluxDB 3.0 Cloud for a client with existing InfluxDB 2.x pain.

If you are picking a time-series database, our data engineering team will look at your real cardinality, ingest rate, query patterns, and retention requirements, then tell you which one we would deploy. The right answer is workload-defined.

Time-series is no longer a single category. Picking by workload shape gets you to the right database faster. Tell us about the data and we will help you choose.