# InfluxDB 3 Core: a Rust time series engine on Parquet, Arrow and DataFusion

> InfluxDB 3 Core is the open source v3 line of InfluxDB, rewritten in Rust around Apache Arrow, DataFusion and Parquet. It keeps line protocol writes and InfluxQL, adds SQL and FlightSQL, and serves its HTTP API on port 8181.

**influxdata/influxdb** — Scalable datastore for metrics, events, and real-time analytics

- Repository: https://github.com/influxdata/influxdb
- Website: https://influxdata.com
- Stars: 31,754 · Forks: 3,717
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/influxdata-influxdb

## What InfluxDB 3 Core is for, and who should pick it over v1 or v2

InfluxDB 3 Core is the open source v3 line of InfluxDB, and this repository holds it on the main branch. The README describes it as a database built to collect, process, transform and store event and time series data, aimed at use cases that need real-time ingest and fast query response. The listed examples are concrete: monitoring sensor data, server monitoring, application performance monitoring, network monitoring, financial market and trading analytics, and behavioral analytics. The common thread is near real-time monitoring where queries back dashboards and interactive interfaces.

The repository carries three versions on separate branches. Main is v3 Core, with SQL and InfluxQL. The main-2.x branch is v2.x with Flux and InfluxQL. The master-1.x branch is v1.x with InfluxQL and Flux. That table matters more than any feature list, because it tells you the v3 rewrite dropped Flux from the open source line and replaced the storage and query stack. If you are starting fresh and your team writes SQL, main is the branch you want. If you have Flux tasks in production, this is not the branch for you.

The project has been generally available since April 2025 according to the README, and the most recent tags in the repository are v3.11.4, v3.11.3 and v3.10.6. The last push to the repository was on 2026-09-10, so this is a codebase with current activity, not an archived one.

## The engine underneath: Arrow, DataFusion, Parquet and a WAL

The design is a departure from the earlier Go implementations. The README states the storage format is Apache Parquet on object storage (S3, Azure, GCP) or local disk, and the build stack is Rust, Apache Arrow and DataFusion. The repository layout confirms the split: the Cargo workspace lists crates named influxdb3_wal, influxdb3_write, influxdb3_query_executor, influxdb3_catalog, influxdb3_cache, influxdb3_server and influxdb3_processing_engine, alongside a large core/ directory of DataFusion and Arrow support crates such as core/iox_query, core/iox_query_influxql, core/flightsql and core/influxdb_line_protocol.

Read that layout as a pipeline. Writes arrive as line protocol and land in the WAL crate. The write crate turns them into Parquet, which the object store layer persists either to local disk or to S3, Azure or GCP. Queries go through a query executor that hands SQL to DataFusion and InfluxQL to a parser and rewrite pair. The catalog crate tracks the schema, and the cache crate sits between queries and storage. The README calls the architecture diskless with object storage support, or local disk with no dependencies.

The practical consequence is that your data is Parquet files. You can point other Parquet readers at the same object store, and you are not locked into a proprietary file format the way you would be with a purpose-built TSDB engine. The cost is that a query engine tuned for Parquet scans behaves differently from one tuned for an in-memory index, and the README does not publish a comparison of the two approaches.

## Installing InfluxDB 3 Core and writing your first point

The README does not give inline install commands. It points to the InfluxData downloads page for Docker images, Debian packages, RPM packages and tarballs, and to the getting started guide at docs.influxdata.com/influxdb3/core/get-started/ for the walkthrough. Building from source is documented separately in CONTRIBUTING.md under the building from source section. The repository does ship a Dockerfile, so a container build is a supported path, but the published images are the ones the README names.

The Dockerfile itself is the only executable artifact the repository gives for setup. It builds from a Rust base image, installs the toolchain dependencies, fetches python-build-standalone, and compiles the influxdb3 package with the aws, gcp, azure and jemalloc_replacing_malloc features enabled by default. The relevant lines are:

```dockerfile
ARG RUST_VERSION=1.92
FROM rust:${RUST_VERSION}-slim-bookworm as build
ARG FEATURES=aws,gcp,azure,jemalloc_replacing_malloc
ARG PACKAGE=influxdb3
```

Those defaults tell you what a stock build includes: object storage backends for the three major clouds and jemalloc as the allocator. If you only need local disk, the FEATURES argument is where you would trim the build, though the Dockerfile does not document a local-disk-only configuration.

Once the server is running, the README states the API is HTTP on port 8181, the write format is line protocol, and the query languages are SQL, InfluxQL and FlightSQL. The README does not publish the exact endpoint paths or request bodies in the text available here, so the getting started guide is where the concrete write and query calls live. What the repository does confirm is the protocol surface: line protocol in, SQL and InfluxQL out, over HTTP on 8181, with FlightSQL as a second query path.

## The embedded Python VM and what it changes about deployment

One feature that separates Core from a plain query engine is the embedded Python VM for plugins and triggers. The workspace includes influxdb3_processing_engine, influxdb3_processing_engine_telemetry, influxdb3_py_api and a README_processing_engine.md at the repository root, which tells you this is a first-class subsystem rather than a side experiment.

The Dockerfile shows how the Python runtime is supplied. It fetches python-build-standalone artifacts via .circleci/scripts/fetch-python-standalone.bash, extracts the target bundle, and rewrites pyo3_config_file.txt so the build links against that interpreter. In other words, the Python version is pinned at build time, not chosen by whatever happens to be on the host. That is good for reproducibility and awkward if you need a specific interpreter version, because changing it means rebuilding the image rather than swapping a system package.

Running user code inside the database process is a real trade-off. A trigger that blocks or leaks memory affects the same process that serves queries. The README does not document resource isolation for plugins, so treat the processing engine as a way to run small transformations close to the data, not as a general sandbox.

## Where InfluxDB 3 Core is the wrong choice

The clearest boundary is Flux. The README's version table lists Flux for v2.x on main-2.x and for v1.x on master-1.x, and lists only SQL and InfluxQL for v3 Core on main. If your dashboards, tasks or alerting rules are written in Flux, adopting this branch means rewriting them. That is a migration project, not a version bump, and the README does not document a Flux compatibility layer for v3.

The second boundary is the user interface. The README describes the API as HTTP on port 8181 and names no web console, and the repository listing shows no frontend directory of the kind a bundled UI would need. If your team expects a point-and-click explorer, plan on Grafana or another client instead. The topics list does include react, which suggests frontend code somewhere in the project's history or tooling, but nothing in the top-level layout or the README describes a shipped browser UI, so do not assume one.

The third is operational scale. Object storage support is listed as a feature, and running against S3, Azure or GCP introduces network latency on every Parquet read that local disk does not have. The README's timing claims (under 10ms for last-value queries, 30ms for distinct metadata) are not qualified by storage backend, so a deployment on object storage should be measured on your own workload rather than assumed from those figures. If your queries are heavy ad hoc scans over years of data, a columnar warehouse may serve them better than a database optimized for recent-window monitoring.

## InfluxDB 3 Core compared with Prometheus and TimescaleDB

Against Prometheus, the difference is in the model and the query surface. Prometheus is a pull-based monitoring system built around scraping targets and a PromQL query language, with a storage engine designed for a retention window. InfluxDB 3 Core takes push writes in line protocol, stores them as Parquet on object storage or local disk, and answers with SQL, InfluxQL or FlightSQL. If your problem is scraping Kubernetes exporters and firing alerts, Prometheus plus Alertmanager is the shorter path. If your problem is storing event and metric data long term, joining it with other tables in SQL, and serving dashboards from a columnar store, InfluxDB 3 Core fits that shape better. The two are not mutually exclusive; a common arrangement keeps Prometheus for alerting and ships data onward for analysis.

Against TimescaleDB, the split is the substrate. TimescaleDB is a PostgreSQL extension, so you get the PostgreSQL wire protocol, the full SQL surface, extensions, joins and transactions, at the cost of running and tuning Postgres. InfluxDB 3 Core is a standalone Rust binary with its own storage format and its own query engine, so there is no Postgres to operate, but there is also no Postgres ecosystem to lean on. The README's compatibility notes point at InfluxDB 1.x and 2.x write and query APIs, not at Postgres tooling. Choose TimescaleDB when your time series data needs to sit next to relational tables in one transaction. Choose InfluxDB 3 Core when ingest rate and a purpose-built time series API matter more than relational joins.

## Licence, releases and the cost of keeping up

The repository ships LICENSE-MIT and LICENSE-APACHE, and the README states the open source software is licensed under the permissive MIT or Apache 2 licenses at the user's choosing, with commercial code kept separate and closed. The GitHub badge in the README reads MIT OR Apache-2.0. For most teams this is the same permissive arrangement as the Rust ecosystem generally, and it does not carry the source-available restrictions some databases have adopted. That is a description of the licence files, not legal advice; if your organisation has a policy on dual-licensed dependencies, run the two licence files past whoever owns that policy.

The upgrade cadence is visible in the release list. Three tags appear within days of each other: v3.11.4 and v3.11.3 both dated 2026-09-08, and v3.10.6 on the same day, which indicates a maintained line plus a backport branch rather than a single moving target. The last push to the repository was on 2026-09-10. If you pin to v3.11.x you should expect patch releases at that rhythm, and the release notes at docs.influxdata.com/influxdb3/core/release-notes/ are where breaking changes would be announced. The README does not document a rollback procedure or a downgrade path between minor versions, so verify that before you upgrade a production instance rather than after.

## Conclusion

Adopt InfluxDB 3 Core if you write line protocol today and want SQL plus InfluxQL against Parquet on local disk or object storage, and you are willing to run the v3 binary rather than the v2 branch. Do not adopt it if you depend on Flux, which the README lists only for the v1.x and v2.x branches, or if you need a browser console, since the README documents an HTTP API on port 8181 and no web UI. Before committing, check the release notes for the v3.11.x line and confirm the Debian, RPM, tarball or Docker artifact you need exists on the InfluxData downloads page.

## FAQ

### Is InfluxDB a SQL database?

InfluxDB 3 Core is, in the sense that the README lists SQL as a query language alongside InfluxQL and FlightSQL, and the query engine is built on DataFusion. Earlier branches differ: v2.x and v1.x list Flux and InfluxQL, not SQL.

### What is the purpose of InfluxDB?

The README describes it as a database for collecting, processing, transforming and storing event and time series data, aimed at real-time ingest and fast query response for dashboards, monitoring and automation. Listed use cases include sensor, server, application performance and network monitoring, plus trading and behavioral analytics.

### Is InfluxDB SQL or NoSQL?

InfluxDB 3 Core is queried with SQL, InfluxQL and FlightSQL, and written with line protocol, which is not a SQL insert statement. So the write path is a purpose-built text format and the read path includes SQL.

### Is InfluxDB better than Prometheus?

They solve different problems, and the README does not compare them. Prometheus is a pull-based monitoring system with PromQL; InfluxDB 3 Core takes line protocol writes and answers SQL, InfluxQL or FlightSQL from Parquet on object storage or local disk. Pick based on whether you need scraping and alerting or long-term storage with SQL.

### How do I install InfluxDB?

The README points to the InfluxData downloads page for Docker images, Debian packages, RPM packages and tarballs, and to the getting started guide at docs.influxdata.com/influxdb3/core/get-started/. Building from source is covered in CONTRIBUTING.md.

### How do I access the InfluxDB API?

The README states the API is HTTP on port 8181, with line protocol for writes and SQL, InfluxQL or FlightSQL for queries. The README does not document a web UI, so access is through HTTP clients, the FlightSQL protocol or a third-party dashboard.

## Sources

- [influxdata/influxdb on GitHub](https://github.com/influxdata/influxdb)
- [License: Apache-2.0](https://github.com/influxdata/influxdb/blob/main/LICENSE)
- [Project website](https://influxdata.com)
- [README](https://github.com/influxdata/influxdb/blob/main/README.md)
- [Releases](https://github.com/influxdata/influxdb/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/influxdata-influxdb