6 Best Time-Series Databases in 2026: An Honest Comparison

The time-series database market in 2026 looks nothing like it did two years ago. Timescale rebranded to Tiger Data. InfluxDB shipped a full Rust rewrite on its third storage engine. GreptimeDB hit 1.0 GA. AWS shut down Timestream for LiveAnalytics. And a new crop of columnar engines are challenging the assumption that time-series data needs its own category of database at all.

If you are evaluating a time-series database right now, the honest answer to "which is best" depends on your workload, your stack, and your tolerance for newer infrastructure. There is no single winner. There are good fits and bad fits, and the difference between them can be an order of magnitude on the queries that matter to you.

I worked at InfluxData. I now run Basekick Labs, where we build Arc, a columnar analytical database. I have opinions, and I will be transparent about them. But this post covers six real options, each one the right answer for a different team, and I will be specific about where each one wins and where it does not.

What the category looks like in 2026

The time-series database category has fragmented into four camps:

1. Metrics-first monitoring. VictoriaMetrics, Prometheus. Optimized for PromQL and observability workloads.
2. SQL-on-time-series specialists. InfluxDB 3, TimescaleDB, Arc. Purpose-built for timestamped data, queried with SQL.
3. Unified observability engines. GreptimeDB. Metrics, logs, and traces in one engine.
4. General-purpose OLAP used for time-series. ClickHouse, Druid, Pinot. Not purpose-built for time-series, but used that way at scale.

The buyer question has shifted from "which is fastest" to "which fits my workload, my stack, and my budget." Here is how to evaluate them.

What to look for

1. Query language. SQL, PromQL, or a custom DSL. Familiar wins.
2. Data model. Pure time-series (tag/field), wide events, full relational, or unified observability covering metrics, logs, and traces.
3. Storage architecture. Local disk, object storage, or hybrid. Object storage scales cheaper. Local disk is faster for hot data.
4. Operational complexity. Single binary vs. clustered with operators vs. external dependencies.
5. License. Apache 2.0, AGPL, source-available, or proprietary. Affects legal risk and whether competitors can fork your stack.
6. Ingestion compatibility. Line Protocol, Telegraf support, OTLP, Prometheus remote-write. Migration cost depends on this.
7. Maturity. Production deployments, community size, support quality.

With those in mind, here are six databases worth evaluating.

1. InfluxDB 3

InfluxDB has been the default time-series database for almost a decade. Version 3 is a complete rewrite: Rust engine (IOx), built on Apache Arrow, DataFusion, and Parquet, with object-storage-backed columnar storage. Core and Enterprise reached GA in April 2025.

What it is best at. If you are already running InfluxDB and your team knows InfluxQL or the new SQL interface, InfluxDB 3 is the path of least resistance. Telegraf is built by InfluxData. Line Protocol is first-class. The v3 architecture (columnar, Parquet-backed, SQL-native) validates where the industry has moved.

Unlimited cardinality is a genuine v3 selling point. Previous versions choked on high-cardinality tag sets. v3 handles them without special configuration.

Where it falls short. Three major-version rewrites in roughly nine years, each with a different query language (InfluxQL, then Flux, then SQL), have stranded teams. The v3 migration from v1 or v2 is a migration, not an upgrade. Teams that bet on Flux in v2 are starting over.

Core is single-node: no clustering, no HA, no replicas. Enterprise adds multi-region durability, read replicas, and automatic failover, but Enterprise pricing is CPU-core-based and adds up fast. The AWS Marketplace listing puts the Enterprise license at $0.198 per vCPU-hour. On a 6-node cluster (96 vCPU), that is roughly $166,500/year in license alone, before infrastructure. We broke down the full math in our TCO comparison of 1 billion rows. Cloud pricing scales with cardinality and ingest volume in ways that surprise teams at scale.

License. Core is open source under MIT/Apache 2.0. Enterprise is commercially licensed.

Best for. Existing InfluxDB users who want to stay in the ecosystem on the new architecture, and teams that value Telegraf integration above all else.

2. TimescaleDB (Tiger Data)

TimescaleDB is a PostgreSQL extension that adds time-series capabilities to standard Postgres. The company rebranded to Tiger Data in June 2025, but the extension is still called TimescaleDB.

What it is best at. If your team runs Postgres, TimescaleDB is the lowest-friction path to better time-series support. Hypertables transparently partition data by time. Continuous aggregates pre-compute rollups. Every Postgres tool, ORM, and client library works. For teams that need both transactional and analytical workloads in the same database, TimescaleDB's Postgres foundation is a real advantage. You are not running two databases.

TimescaleDB now ships Hypercore, a hybrid row-and-columnstore engine. Hot data lives in row format for fast writes and updates. Cooled data is automatically migrated to a compressed columnstore. The original critique that "everything decompresses back to rows" is no longer fully accurate.

Where it falls short. The executor is still primarily Postgres's row-based engine. Vectorized paths exist for specific operators, not the whole query plan. On heavy aggregation workloads over very large datasets, you can feel the gap against engines that are columnar end-to-end. We measured this directly: on ClickBench, Arc was 4.6x faster than TimescaleDB on combined score.

There is no native Line Protocol support. The outflux migration tool only covers InfluxDB v1.x. Teams migrating from InfluxDB v2 or v3 need custom ETL and should expect schema redesign work.

License. Dual-licensed. Apache 2.0 for core hypertable functionality. The features most teams actually want (Hypercore, continuous aggregates, retention policies, advanced hyperfunctions) are under the Timescale License (TSL), source-available but not OSI-open-source. TSL prohibits offering TimescaleDB as a managed service.

Best for. Postgres shops that want time-series capabilities without leaving the Postgres ecosystem, with workloads that fit below roughly 100M rows per hypertable.

3. VictoriaMetrics

VictoriaMetrics is a Prometheus-compatible metrics database written in Go. It ships as a single binary or as a clustered version with separate ingestion, storage, and query components.

What it is best at. If you run Prometheus and you are hitting its retention or scale limits, VictoriaMetrics is the cleanest upgrade. It speaks PromQL. It accepts Prometheus remote-write. It works with existing Grafana dashboards and Alertmanager rules without modification.

Operationally, it is dramatically simpler than most alternatives. The single-binary deployment is genuinely single-binary. Compression is excellent: typical observability workloads compress 10x or better. The company is bootstrapped, profitable, and crossed 1 billion Docker downloads in 2025.

A notable adoption signal: OpenAI's engineering team published that their internal Codex observability stack runs on VictoriaMetrics, VictoriaLogs, and VictoriaTraces.

Where it falls short. VictoriaMetrics is a metrics database. Logs and traces are handled by separate products (VictoriaLogs, VictoriaTraces) with separate query interfaces. VictoriaTraces is still pre-1.0 (v0.9.x as of July 2026). If your goal is one engine for everything, VictoriaMetrics is three engines from one vendor.

PromQL is powerful for metrics but does not have the analytical depth of SQL. Joins, window functions, and complex cross-dimension aggregations will push you toward SQL.

License. Apache 2.0. Enterprise adds downsampling, advanced multi-tenancy, and audit logs.

Best for. Teams replacing Prometheus who want a metrics-first solution with excellent compression and minimal operational overhead, and who are comfortable with PromQL.

4. GreptimeDB

GreptimeDB is a Rust-based database that unifies metrics, logs, and traces in a single engine. v1.0 GA shipped in April 2026.

What it is best at. GreptimeDB is the most ambitious unified observability play on this list. Metrics, logs, traces, and wide events all live in one engine, timestamped and queryable with the same SQL. Cross-signal joins are an explicit design goal. If you have been running Loki for logs, Prometheus for metrics, and Jaeger for traces, GreptimeDB proposes consolidating all of that into one system.

It supports ANSI SQL, PromQL, and a streaming interface (Flow). Native OTLP ingestion and Jaeger Query API are built in. Object storage support covers S3, GCS, Azure Blob, Aliyun OSS, and MinIO. GreptimeDB Edge exists for resource-constrained environments (IoT, automotive, ARM).

GreptimeDB reports 2.17x TimescaleDB on TSBS ingestion (285K vs 131K rows/sec) and gRPC Bulk/Arrow throughput of roughly 2.68M rows/sec on an M4 Max.

Where it falls short. Maturity. v1.0 GA is only months old. Production deployments at large scale are still accumulating. The Rust database tooling ecosystem is younger than Go's or Java's, which means fewer integrations and a smaller pool of operational expertise.

The reference production deployment is OceanBase Cloud running 80+ GreptimeDB clusters managing 300 TB of logs. That is a real signal, but it is one customer, and it is a log-specific workload.

License. Apache 2.0 (core). Enterprise features are gated behind a separate license. Enterprise pricing is not public.

Best for. Cloud-native, Kubernetes-first teams that want to consolidate observability into one engine and are comfortable adopting newer infrastructure.

5. ClickHouse

ClickHouse is a general-purpose columnar OLAP database, not a purpose-built time-series engine. It is the database most often benchmarked against purpose-built TSDBs, and it wins a lot of those benchmarks.

What it is best at. Heavy analytical queries over very large event datasets. ClickHouse posts the smallest ClickBench loaded size on the standard 100 GB dataset. The scale evidence is real: Cloudflare runs over a thousand active replicas processing hundreds of millions of rows per second, and has published a case study describing a single query that scanned 96 trillion events in an hour.

If your time-series workload is really an analytical workload (heavy aggregations, complex filters, large joins over event data), ClickHouse is arguably the most battle-tested engine on this list.

Where it falls short for time-series. Time is "just another column" in ClickHouse, not the storage organizer. That is the key architectural difference from purpose-built TSDBs. Last-point queries, time-bucketed aggregations, and time-range scans are not optimized the way they are in engines designed around timestamped data.

Operational complexity is higher than most alternatives. Clustering requires careful segment management. PromQL support is early-stage. OTLP ingestion flows through a separate ClickStack layer (Redis/Kafka buffering, ingestion workers) rather than being native. There is no built-in streaming ingestion; you use Kafka connectors instead.

License. Apache 2.0.

Best for. Teams with heavy analytical workloads on very large event datasets, who need raw query power more than time-series-specific features.

6. Arc

Arc is a columnar analytical database for metrics, logs, traces, and events. I built it after leaving InfluxData. It uses DuckDB for the query engine and stores data as native Apache Parquet on S3, Azure Blob, MinIO, or local disk.

I am including Arc here because I believe it is the best option on this list for a growing set of time-series workloads. I will be transparent about why, and about where it does not fit yet.

What it is best at. Metrics, logs, and traces in one engine. Arc handles the full observability stack, not just one signal. Ingest all three through the same ingestion paths, store them in the same Parquet files, query them with the same SQL. No need to run separate databases for metrics and logs and stitch them together at query time.

Ingestion and query performance. Arc ingests at 20M records/sec via MessagePack columnar protocol and 4.1M records/sec via Line Protocol. On ClickBench, Arc beats TimescaleDB on combined score by 4.6x and on ingestion by 9.6x. Against InfluxDB 3, Arc is 5x faster on ingestion than InfluxDB 3 Core and 10x faster than InfluxDB 3 Enterprise. We covered the full numbers in the Arc vs TimescaleDB and Arc vs InfluxDB benchmarks.

Drop-in InfluxDB compatibility at the ingestion layer. Existing Telegraf agents work without modification. Influx Line Protocol is a first-class ingestion path. Teams have migrated production InfluxDB workloads to Arc by changing the destination URL.

DuckDB SQL means full standard SQL: window functions, CTEs, complex joins, analytical functions. If your team knows Postgres SQL, you already know how to query Arc.

Storage is plain Apache Parquet, on storage you own. No proprietary format. If you leave Arc, your data is already readable by DuckDB, Spark, Polars, ClickHouse, BigQuery, or anything else that reads Parquet. There is no export step. We covered why this matters in Parquet vs Proprietary Formats.

Single Go binary. No JVM, no external dependencies. Arc uses 1.3x less storage than TimescaleDB on the same ClickBench dataset.

Where it falls short. Arc is the newest database on this list. It has been live since October 2025, roughly nine months. Early production deployments exist, but the community is smaller (roughly 600 GitHub stars) and the battle-test clock has not had time to run.

The license is AGPL-3.0. This is intentional: it prevents cloud providers from forking Arc into a commercial offering without contributing back. But some enterprises avoid AGPL for legal reasons. Arc Enterprise is commercially licensed and avoids this concern.

Clustering and HA are Enterprise features, not OSS.

License. AGPL-3.0 (community), commercial (Enterprise).

Best for. Teams that want the fastest analytical SQL on time-series data, value Parquet portability, and want drop-in InfluxDB compatibility. If you are evaluating a move from InfluxDB, we covered the full migration path in Migrating from InfluxDB to Arc.

Decision Matrix

The 2026 market shifts worth knowing

A few things happened this year that change the calculus:

Tiger Data rebrand. Timescale Inc. rebranded to Tiger Data in June 2025. The extension is still TimescaleDB, but the company is pushing Tiger Lake, an Iceberg-backed object storage layer. The direction is clear: hybrid row-columnar on Postgres, with an eye toward lakehouse architectures.

InfluxDB 3 GA. After roughly nine years across three major versions, InfluxDB 3 reached GA in April 2025 on a Rust/Arrow/Parquet rewrite. The architecture is good. The migration path from v1 and v2 is not trivial.

GreptimeDB v1.0 GA. April 2026. The unified observability bet is now a real product, not a beta. It will take another year of production deployments before teams can evaluate it with confidence.

AWS Timestream shutdown. AWS closed Timestream for LiveAnalytics to new customers in June 2025. The company now steers users toward Timestream for InfluxDB, which added InfluxDB 3 support in October 2025. If you were waiting on AWS to solve your time-series problem, the answer is now "use InfluxDB."

How to pick

Shortlist by workload, not by benchmark ranking:

• Metrics and Prometheus? VictoriaMetrics.
• Postgres shop with relational and time-series needs? TimescaleDB.
• Unified metrics, logs, and traces, Kubernetes-native? GreptimeDB.
• Heavy ad-hoc analytics on huge event tables? ClickHouse.
• Existing InfluxDB investment, want to stay in ecosystem? InfluxDB 3.
• Want metrics, logs, and traces in one engine with the fastest analytical SQL, Parquet portability, and drop-in InfluxDB ingestion? Arc.

Then run a two-week proof of concept on your own data. Every engine on this list is capable. Reproduce ingestion at your real cardinality. Run your five heaviest dashboard queries. Let the data decide.

Treat license as a gating criterion early. If your legal team bars AGPL, Arc OSS is out before you start. If you might resell as a managed service, TimescaleDB's TSL features and GreptimeDB Enterprise terms matter. Apache 2.0 (VictoriaMetrics, ClickHouse) is the least friction.

Conclusion

There is no best time-series database in 2026. There are good fits for specific workloads. The category has matured to the point where the real differentiators are operational model, storage portability, query language fit, and license.

The honest advice: do not pick a database from a blog post. Pick a shortlist, run a proof of concept on your actual workload, and let the data decide.

This post will be updated quarterly. Last updated July 2026. If something is wrong or out of date, tell me on GitHub or in Discord.

---

Explore Arc:

• Arc documentation
• Compare Arc vs Elasticsearch
• Compare Arc vs InfluxDB
• Compare Arc vs ClickHouse
• Migrating from InfluxDB to Arc
• Arc Enterprise Managed for managed hosting
• Star Arc on GitHub

---

About the author. I am Ignacio Van Droogenbroeck, founder of Basekick Labs and an ex-InfluxData engineer. I have been working with time-series data since 2018. I built Arc because I believe telemetry infrastructure should be built on portable, columnar formats, not proprietary engines. The other five databases on this list are all real, valid choices for the right team.