InfluxDB 3 Core Benchmarks: QuestDB Comparison

Last updated August 28, 2026

This article benchmarks InfluxDB 3 Core against QuestDB 9.3.3. InfluxDB 3 Core, which reached general availability in April 2025, is a complete rewrite of InfluxDB using Apache Arrow and DataFusion.

Key results: QuestDB ingests 7 to 8.6 million rows per second at every cardinality we tested; InfluxDB 3 Core holds a flat 319K. On queries, InfluxDB 3 Core is slower than QuestDB on every type and slower than InfluxDB v1 and v2 on most. Simple one-hour aggregations take around 55 ms against QuestDB's sub-millisecond, and the full-table scan is the one place the two are close, 1.24 s against 1.03 s.

For InfluxDB v1/v2 benchmarks and detailed architecture comparison, see QuestDB vs InfluxDB.

About InfluxDB 3 Core

InfluxDB 3 Core represents a major architectural shift for InfluxDB:

• Complete rewrite in Rust (previously Go)
• Apache Arrow for in-memory data representation
• DataFusion query engine (Apache Arrow's SQL query engine)
• Parquet for storage format
• Arrow Flight for query protocol (gRPC-based)

It is a different database from v1 and v2, built around columnar processing for analytical queries.

Performance benchmarks

We use the open-source, industry-standard Time Series Benchmark Suite (TSBS) for all benchmarks. TSBS was created by Timescale and has seen no real development upstream since 2023, so we maintain our own fork. We extended the InfluxDB query runner to support v3 via Arrow Flight using the official influxdb3-go client library.

Hardware: AWS EC2 r8a.8xlarge (32 vCPU, 256 GB RAM, AMD EPYC), GP3 EBS storage (20,000 IOPS, 1 GB/s throughput)

Software:

• Ubuntu 22.04
• InfluxDB 3 Core 3.10.0
• QuestDB 9.3.3

Measured: InfluxDB 3 Core 3.10.0, benchmarked August 2026. QuestDB 9.3.3, on the same r8a.8xlarge instance. New benchmarks on QuestDB 10.0 are coming.

Core allocation: the TSBS client and the database run on the same instance with no CPU pinning.

Query statistic: each figure is the median latency within a run, averaged over 3 runs, with a warm query cache. InfluxDB 3 Core ran 50 queries per type where QuestDB ran 1,000, because at the full count it did not complete a pass in 18 hours. Its query figures carry correspondingly less statistical confidence.

Ingestion benchmark

We test a cpu-only scenario across four cardinality levels, from 1,000 to 1M simulated hosts. We start at 1,000 hosts. Smaller datasets finish in under a second on the faster engines, where setup cost dominates and the result stops measuring throughput.

Example commands:

$ ./tsbs_generate_data --use-case="cpu-only" --seed=123 --scale=4000 \
    --timestamp-start="2016-01-01T00:00:00Z" \
    --timestamp-end="2016-01-03T00:00:00Z" \
    --log-interval="10s" --format="influx" > /tmp/influx_data

$ ./tsbs_load_influx --db-name=benchmark --file=/tmp/influx_data \
    --urls=http://localhost:8181 --workers=32

The same data, seed and worker count against QuestDB:

$ ./tsbs_generate_data --use-case="cpu-only" --seed=123 --scale=4000 \
    --timestamp-start="2016-01-01T00:00:00Z" \
    --timestamp-end="2016-01-03T00:00:00Z" \
    --log-interval="10s" --format="questdb" > /tmp/questdb_data

$ ./tsbs_load_questdb --file=/tmp/questdb_data --workers=32

Neither loader is given a batch-size flag, so both run the TSBS default of 10,000 rows per batch.

The results for ingestion with 32 workers:

Key observations:

• InfluxDB 3 Core shows constant ~319K rows/sec regardless of cardinality (1,000 to 1M hosts)
• QuestDB holds 7.1M to 8.6M rows/sec across the whole range, peaking at 100K hosts

Query performance

All queries run with a single worker to measure per-query latency.

Dataset: cpu-only scenario, 4,000 hosts, 10-second intervals, 2 days of data (~69M rows)

The TSBS suite has six families:

• single-groupby: Aggregate CPU metrics for random hosts over specified time ranges
• double-groupby: Aggregate across ALL hosts, grouped by host and time intervals
• cpu-max-all: Maximum of all ten CPU metrics across 1, 8 or 32 hosts
• high-cpu-1 and high-cpu-all: Hosts with CPU utilization above a threshold, for one host and for the full table
• lastpoint: The most recent reading for every host
• groupby-orderby-limit: Top-N aggregation over a time range

To run the benchmark:

$ ./tsbs_generate_queries --use-case="devops" --seed=123 --scale=4000 \
    --timestamp-start="2016-01-01T00:00:00Z" \
    --timestamp-end="2016-01-03T00:00:00Z" \
    --queries=1000 --query-type="single-groupby-1-1-1" \
    --format="influx" > /tmp/influx_query

$ ./tsbs_run_queries_influx --file=/tmp/influx_query \
    --db-name=benchmark --workers=1

And against QuestDB:

$ ./tsbs_generate_queries --use-case="devops" --seed=123 --scale=4000 \
    --timestamp-start="2016-01-01T00:00:00Z" \
    --timestamp-end="2016-01-03T00:00:00Z" \
    --queries=1000 --query-type="single-groupby-1-1-1" \
    --format="questdb" > /tmp/questdb_query

$ ./tsbs_run_queries_questdb --file=/tmp/questdb_query --workers=1

Single-groupby queries

Query names encode metrics, hosts and hours: 5-8-1 is five metrics, eight hosts, one hour. Every query on this page is described in the appendix.

Double-groupby queries

CPU-max-all and high-cpu queries

Lastpoint and top-N queries

lastpoint fetches the most recent reading for every host. QuestDB answers it in 1.7 ms with LATEST ON. InfluxDB 3 Core takes 54 seconds, which is why it ran 50 queries per type here rather than the 1,000 used for QuestDB: at the full count a single pass did not finish.

Heavy queries

Explaining performance differences

InfluxDB 3 Core observations

Ingestion: The consistent ~319K rows/sec throughput across all cardinality levels suggests the bottleneck is not related to series management (unlike v1/v2) but rather in the write path itself, possibly WAL handling, Parquet encoding, or HTTP request processing.

Queries: Results show consistent ~55-65 ms latency for simple 1-hour queries regardless of the number of metrics or hosts queried. This suggests a fixed per-query overhead, possibly from:

• Arrow Flight connection/protocol overhead
• DataFusion query planning

Longer time ranges (12-hour queries) scale linearly with data volume, reaching ~630-640 ms. The heavy analytical query (high-cpu-all) has improved sharply in recent releases, from more than 16 seconds to 1.2 seconds.

Comparison with InfluxDB v1/v2

InfluxDB 3 Core is slower than InfluxDB v1 and v2 on most of this suite:

The Arrow and DataFusion stack is young; expect it to improve.

QuestDB performance

QuestDB maintains sub-2 ms latency on single-groupby queries and 32-56 ms on full-table double-groupby aggregations. Ingestion peaks at 8.59M rows/sec at 100K hosts.

Conclusion

InfluxDB 3 Core is InfluxData's bet on the Apache Arrow ecosystem. Today it is slower than both QuestDB and the older InfluxDB versions on most of this suite, but the foundation (Arrow, DataFusion, Parquet) is sound, and the cardinality-based degradation of v1 and v2 is gone.

QuestDB ingests several times faster and answers most queries in a fraction of the time. Where ingestion throughput and query latency matter, it is the faster choice.

We will re-run this on new InfluxDB 3 Core releases.

Ready to try QuestDB? Get started with the quickstart guide or join our Slack community.

Appendix: what each TSBS query does

Query names encode their parameters: single-groupby-5-8-1 is five metrics, eight hosts, one hour.

Definitions follow the TSBS README. Every query is generated with seed 123 against the 4,000-host dataset, so each engine answers the same random hosts and time ranges.

More database comparisons

|

Read

QuestDB vs. Clickhouse

Benchmarks and architecture comparison.

|

Read

QuestDB vs. TimescaleDB

Native time-series vs PostgreSQL extension.

|

Read

QuestDB vs. InfluxDB

Benchmarks and performance comparison.