InfluxDB 3

What it is

InfluxDB 3 is the third engine to carry the name and shares almost nothing with the first two. It is written in Rust on what InfluxData calls the FDAP stack — Apache Flight, DataFusion, Arrow and Parquet — so rows arrive as line protocol, land in a write-ahead log, and persist as Parquet files on local disk or S3-compatible object storage. Queries are SQL through DataFusion, or InfluxQL for the 1.x-era clients that still exist.

The rewrite fixed the thing that disqualified InfluxDB for market data. In 1.x and 2.x every distinct tag combination became an indexed series held in memory, so a per-symbol, per-venue schema blew up the cardinality budget. Parquet has no in-memory series index; selectivity comes from row-group statistics, and cardinality stops being the number you design around. What replaces it as the number to watch is file count.

Core is generally available since April 2025 and shipping steadily, with v3.11.5 published in September 2026. It is a real database with real caps: 5 databases, 2000 tables across all of them, 500 columns per table, one node, and no compactor, so the small Parquet files it writes are never merged into larger ones.

Pricing

Core is free and permissively licensed; the paid line starts where Core's caps bite. Enterprise adds compaction, historical query performance, high availability, read replicas and multi-node clustering, and it is sold per CPU core in batches of 8 to 128 with no published figure — the only public numbers on the licence page are the trial's 30 days and 256-core ceiling and the at-home licence's two cores.

The managed side is where prices are actually printed. Cloud Serverless meters four dimensions separately — bytes written, queries executed, GB-hours stored and bytes out — which for a tick workload makes the storage and write lines the ones to model before signing up. Cloud Dedicated is a quote.

Data & coverage

None. InfluxDB ships no market data; every tick in it is one you wrote.

Integrations

Line protocol over HTTP is the write path, compatible with 1.x and 2.x clients and with Telegraf. Reads come back over Flight SQL, an HTTP query API or the CLI. An embedded Python virtual machine runs plugins and triggers inside the database on write or on a schedule, which is how you downsample ticks to bars without a separate job runner. InfluxData publishes its own MCP server — @influxdata/influxdb3-mcp-server on npm, and note that the unscoped influxdb-mcp-server name belongs to an unrelated community project. The Python client is influxdb3-python, maintained in InfluxData's community organisation rather than the main repository.

Limitations

• No ASOF JOIN. The SQL reference documents inner, left, right and full joins and nothing else, so every trade-to-quote match is a window function or a lateral you write and tune.
• Core has no compactor, which is the real meaning of the 72-hour figure — long-range queries read hundreds of small files, and the fix is a licence rather than a setting.
• Five databases and 2000 tables is a low ceiling if your instinct is a table per symbol.
• Schema is line protocol's, tags and fields, not arbitrary SQL DDL — a tick schema has to be expressed in that shape before anything else works.
• The free Enterprise tier bars commercial use, so a one-person trading business is on Core or on a contract, not on the at-home licence.
• No market data, no symbology, no corporate actions.

Alternatives

QuestDB is the closest substitute and the better fit here — it also takes line protocol, and it has ASOF JOIN, SAMPLE BY and LATEST ON under Apache-2.0 with no database or table caps. ClickHouse for wide historical scans; TimescaleDB if the rest of the stack is Postgres; DuckDB if nothing is streaming in and a file is enough.

See the rest of the tick data storage category.