InfluxDB 3 Core stores Parquet and speaks SQL or InfluxQL
The main branch is InfluxDB 3 Core, a Rust database for time-series and event data. It accepts line protocol, stores Parquet on local disk or S3, Azure, or GCP object storage, and serves SQL, InfluxQL, FlightSQL, and HTTP queries. Existing InfluxDB 1.x and 2.x writers can use compatible write APIs. Users migrating from 2.x should notice that Flux remains on the main-2.x branch rather than the v3 query surface.
An embedded Python VM powers plugins and triggers for processing data inside the server. That can reduce the distance between ingestion and automation, yet it also makes Python part of the database runtime. Plugins may receive write-ahead-log events, scheduled calls, or HTTP requests. Version v3.10.0 added flags that restrict which trigger types may run and can confine plugin files to one directory. Production deployments should use those restrictions rather than treating plugin code as ordinary SQL.
The source build stopped after 567 seconds on libpython3.11
Our Rust install phase succeeded in 153 seconds and pulled 803 packages. The checkout had 1,794 files, about 395,555 source lines, and occupied 23.3 MB before Cargo dependencies. It included a Dockerfile and 1 CI workflow file, with no top-level tests directory. Rust commonly keeps unit tests beside source files, so directory layout alone says little about coverage. The long compilation made the final linker failure costly to discover.
After 567 seconds, the build exited with code 101. The linker reported rust-lld: error: unable to find library -lpython3.11, followed by failure to compile the influxdb3 binary. The log does not show another compiler error. InfluxDB's processing-engine guide explains that PyO3 finds a Python runtime during the build and dynamically links its libpython; the documented Debian packages include python3-dev, along with compiler, SSL, and protobuf dependencies.
What happened when we ran it
The test command failed with exit code 101 after 45 seconds and reached the same missing -lpython3.11 linker error. No completed test count appeared, so there is no passing or failing assertion total to report. Our result covers commit 693b1fd in an unprivileged container with 3 CPUs and 12 GB of RAM. It shows that the general Rust image did not satisfy this repository's native Python link requirement.
We did not start a database, write line protocol, query Parquet, attach object storage, run a Python trigger, or measure latency and throughput. The README contains performance examples, but our lab did not reproduce them, so they are not evidence in this review. Packaged downloads bundle a controlled Python distribution and are the fairer path for an operator trial. Source contributors need Python development files, protoc, and a build environment that keeps the matching Python library available at runtime.
Version 3.10.0 migrates the catalog in one direction
InfluxDB 3 Core has been generally available since April 2025. Release v3.10.0, published June 17, 2026, moves the on-disk catalog to a new binary format during first startup. The release notes call the migration automatic and crash-safe, while also warning that it is one-way and that 3.9.x cannot read the result. They instruct operators to back up the catalog directory and checkpoint before upgrading. That backup is the rollback plan.
The same release added a readiness endpoint that checks object-store reachability, cross-database reads for plugins, offline catalog inspection, and trigger restrictions. Startup flags and some HTTP status behavior changed too. A database upgrade deserves a staging restore in addition to a successful process restart. Copy production-shaped metadata, perform the migration, check writer and query clients, stop the service, and prove that the documented backup can restore into the intended recovery version.
Open v3 issues affect query truth and client availability
Issue 27384 is labeled for v3 Core and reports incorrect InfluxQL SPREAD output when values are negative. A related fix pull request was active in August. Any alert, dashboard, or billing job using that function should have a regression query with known negative data. Database correctness bugs are dangerous because a successful HTTP response can carry the wrong answer without alerting the caller.
Issue 27591 concerns influxdb3_client, the Rust v3 client. The report says its HTTP client has no request timeout or configuration option, allowing a connection that never responds to wait indefinitely. Applications can wrap calls with their own deadline, but that behavior belongs in an integration test before the client reaches a request path. Issue 27329 separately reports the v3 RPM service failing on Rocky Linux 9 and 10 due to systemd namespace setup.
Active maintenance spans 3 major version lines
GitHub showed 31,717 stars, 2,151 combined open issues and pull requests, and a last push on August 25, 2026. That open count covers work across v1, v2, and v3 branches, so it is not a v3 bug total. The recent list included current fixes for v3 query ordering and legacy import or replication work. Version labels and branch names matter whenever an issue is used to judge this product.
InfluxDB 3 Core is worth evaluating when line protocol, Parquet storage, and SQL or InfluxQL fit an existing telemetry pipeline. Our failed source build is a setup finding, not a database benchmark. Begin with the official package, pin v3-specific clients, test negative-value queries, and isolate Python plugins. Before v3.10 touches real metadata, make the catalog backup and rehearse a restore that does not depend on downgrading the migrated files.