InfluxDB v3: Why Rust Beat Go for Time Series Database
It became clear in 2020 that the time was right to shift InfluxDB to Rust, enabling it to offer key features that were previously limited — though not impossible — to achieve with Go. After foregoing Go to rewrite v3, which was recently released in Rust, the project has also heavily relied on DataFusion for core capabilities.
Flash forward to over four years later. These capabilities include cardinality (or so-called infinite cardinality), SQL querying and the separation of compute and storage, such as using object stores like S3. DataFusion allows those features to be integrated with InfluxDB v3. InfluxDB itself is now written in Rust to improve the functionality of libraries and the integration of querying features.
Whether this big bet on Rust pays off or not, beyond those who might have preferred the simpler language of Go for its development, InfluxDB v3 represents an ambitious attempt and major work to deliver many much-needed features lacking in the previous version. InfluxDB is now at least better positioned as a leading alternative for time series database requirements, especially for edge devices and edge computing.
“Any CTO who wants to track data from machines — whether virtual sensors (application metrics, events) or physical sensors (edge deployments) — can benefit from InfluxDB,” InfluxData CTO and founder Paul Dix told me in May in Seattle during GrafanaCon, Grafana Labs’ annual users conference.
Customers typically use InfluxDB alongside Grafana and other tools for logs and tracing. In the industrial Internet of Things (IoT) sector, InfluxDB is used in deployments related to satellites, rockets, energy, mining, oil and gas. The platform serves between 3,000 to 4,000 customers, with a significantly larger base of users overall, Dix said.
Rust Up
.@InfluxDB founder Paul Dix on open source InfluxDB 3 Core and rewriting the database in Rust: « The culmination of a 4.5-year journey about rebuilding..has been a long and difficult road, » at GrafanaCon 2025. @grafana @thenewstack pic.twitter.com/9yD4z3vizw
— BC Gain (@bcamerongain), May 8, 2025
The shift to Rust addressed three major objectives: support for infinite cardinality, enabling SQL querying and decoupling compute from storage to leverage lower-cost object stores. Development began in 2020 and took approximately four and a half years.
As mentioned above, the choice of Rust was driven by architectural considerations rather than limitations in Go. Specifically, the aim was to integrate an off-the-shelf query engine. While many mature engines are written in Java, C or C++, Rust offered better interoperability with C than Go, Dix said.
Ultimately, InfluxData incorporated DataFusion into the project, a Rust-based query engine and sub-project of Apache Arrow. Contributions to DataFusion began in 2020, and the team now leads the project, with one of their engineers serving as a PMC member for both Arrow and DataFusion, Dix said.
“The philosophy behind this open source work is to commoditize dependencies, similar to how Facebook handled data center designs and how Google created Kubernetes in part to compete with Amazon,” Dix said. “By focusing on solving time series problems rather than building a query engine from scratch, InfluxDB can deliver more value. Contributions from other major companies — such as Apple, Alibaba and Datadog — have further strengthened the DataFusion project.”
Grafana, often used with InfluxDB, currently supports PromQL, LogQL and TraceQL as its query languages. “SQL is not yet a first-class language in Grafana, but if that were to change, DataFusion would likely be the underlying engine,” Dix said.
Launched in beta in March, InfluxDB 3 Core is InfluxData’s new open source product, licensed under MIT/Apache 2.
InfluxDB 3 Enterprise is a commercial version of Core with performance optimizations for queries over time ranges longer than an hour, as well as support for longer-term historical queries, high availability, enhanced security and multinode deployments, Dix said.
The Full Stack
“InfluxDB 3 is built on what we call the FDAP stack: Apache Flight, DataFusion, Arrow and Parquet,” Dix wrote in a blog post. “Paired with the ability to run with all persisted state on object storage (or local disk if preferred), this enables new features and advantages over previous versions of InfluxDB. Apache Arrow, an in-memory columnar format, enables data sharing across system components and fast vectorized query execution,” Dix said.
“DataFusion is a vectorized SQL query engine that takes full advantage of this format. By contributing to DataFusion, we stay close to the engine and the community driving it forward,” Dix said. “Every performance gain and new feature flows straight into InfluxDB 3, accelerating its maturity with each release.”
Parquet serves as InfluxDB’s persistence format for improvised compression of time series data. “Paired with DataFusion’s native support for Parquet and push-down optimizations, we achieve exceptional performance on time series analytic queries that were out of reach of previous versions of InfluxDB,” Dix wrote. “Flight and FlightSQL give InfluxDB 3 the ability to serve query responses with millions of rows without expensive serialization. We also have an easy-to-use HTTP API for requests that don’t require the performance of FlightSQL.”
Both InfluxDB 3 Core and Enterprise are based on that same architecture and purpose-built for the future of time series data:
“Developing InfluxDB on the FDAP stack gives us a flexible, efficient architecture that delivers significant performance gains—higher ingest, better compression, faster queries, and no limits on cardinality. It provides efficient storage and real-time analytics, even as your data grows in volume and complexity,” Dix wrote.
“For developers, it means building on a system that’s fast, reliable, and purpose-built for time series. Operationally, it handles high-concurrency workloads, maintains data integrity, and stays resilient under pressure. Architecturally, it scales both out and up, adapting seamlessly as workloads change.”
Dix continued: “That foundation is possible because we’re not just using open standards like Arrow, Parquet, and DataFusion—we’re helping shape them. Alongside InfluxDB 3 Core, we’re investing in the FDAP stack and contributing upstream, often leading the work. Those improvements flow directly into InfluxDB 3, delivering better features, easier integration, and software tested across a wide range of environments. That’s the value of open source: maturity and resilience you don’t get from closed systems.”
InfluxData has introduced several features in InfluxDB 3 Core and in the enterprise version to optimize common query patterns in time series data, Dix wrote. This translates into how the Last Value Cache (LVC) and the Distinct Value Cache (DVC) can answer queries in under 10 milliseconds, for more responsive UIs and fast monitoring systems, Dix wrote.
Other new features in v3 Dix communicated include:
- LVC: Configurable to keep the most recent values for specified tag hierarchies. The latest metrics for a specific sensor, all sensors on a machine, or all sensors in a factory, can be “instantly retrieved.”
- DVC: This was designed to offer fast lookups for tag values and series metadata, making UI dropdowns and exploratory queries more responsive.
“One of the most significant additions in InfluxDB 3 is the embedded Python Processing Engine. It brings computation directly into the database, allowing data transformation, enrichment, monitoring, and alerting without external services or pipelines. The Processing Engine runs a lightweight Python VM inside the database and executes your code based on triggers—on ingest, on a schedule, or in response to an HTTP request,” Dix wrote.
