Two years after releasing the GA version of InfluxData’s enterprise edition, their open-source version also reached that level of maturity. Conceptualised for real-time workloads and ease of running, the core version leaves aside features like long-term storage optimisations, compaction or high availability (HA), read replicas, or fine-grained access controls.
The third version of the data product goes beyond the traditional scope of data storage functionality. It incorporates an embedded Python VM, allowing developers to extend the way they collect, process, and alert on real-time data. InfoQ contacted Paul Dix, cofounder and CTO of InfluxData, to better understand how the open-source version compares with the enterprise one and whether to use one or the other.
InfoQ: Thank you for taking the time to answer some questions for our readers. Let’s start by asking you to introduce yourselves and describe your day-to-day duties at InfluxData.
Dix: I’m the founder and CTO of InfluxData, the time series database InfluxDB creator. I lead product strategy and the development of InfluxDB 3. Ultimately, my job is to keep us pointed in the right direction technically and in how we present ourselves to the developer community.
InfoQ: What prompted the decision to develop an open-source database version alongside the enterprise edition?
Dix: Infrastructure software should be open, hackable, and easy to run on your terms. That’s why I believe open-source is the foundation of every product. We envision it: you can start with the core version, bootstrap your system, and as it scales and the requirements change(you need long-range queries, high availability, and multi-node deployments), you can opt to use the enterprise version. We built the core version as the foundation, supporting infinite cardinality, designed with a “diskless” architecture, while the enterprise version adds the complexities for commercial workloads.
InfoQ: What challenges or limitations should users be aware of when using the open-source version compared to the enterprise edition?
Dix: InfluxDB 3 Core is optimised for real-time workloads, such as edge data transformation, streaming analytics, and sensor-based alerting—any use case where low-latency insights are critical. The core was thought to provide a solid foundation for local dev, edge devices, or lightweight monitoring setups. However, the enterprise is better suited for more complex historical queries or scaling across multiple nodes. We also have a free enterprise tier designed for hobbyists and at-home use. It runs as a single node and includes features like the compaction engine, which makes it easier to work with historical data.
InfoQ: How does the database compare to other players in the space?
Dix: We didn’t want another general-purpose engine adapted for time series. Based on our experience, we designed Influxdb 3 specifically for time series data, targeting high ingestion rates, low-latency queries, and efficient data compression. Using the FDAP stack —Flight, DataFusion, Arrow, and Parquet— we aimed to facilitate its data ecosystem integration.
InfluxDB 3 is an active layer in data pipelines, integrating computation with storage via the embedded processing engine. It supports single-process operations and horizontal scaling, with capabilities for data transformation in Python and SQL querying, distinguishing it from other time series databases.
InfoQ: How was the rewriting experience?
Dix: Rewriting a time series database from scratch isn’t something you do lightly. The real complexity came from trying to hit all the design goals at once—supporting object storage as the persistence layer, delivering millisecond query latency, running on top of a general-purpose SQL engine, and keeping things simple to operate.
InfoQ: What’s next on InfluxData’s roadmap? What will be available in the core version?
Dix: We’re investing heavily in the Processing Engine, one of the most essential parts of InfluxDB 3 Core and Enterprise. The Processing Engine represents a fundamental shift in what a database can do.
Traditionally, databases are passive: you write data in and query it later. A database should be able to do more, so we are investing heavily in the processing engine, targeting to transform InfluxDB into an active intelligence engine that can react to data as it streams in.
The Processing Engine is a lightweight Python VM embedded directly inside the database. Using code they already know, users can build everything from real-time anomaly detection to scheduled reports to custom ETL flows within the database.
InfluxDB 3 Core data promises to provide the same experience as its enterprise version. However, it lacks storage optimisations, compression, HA, read replicas, or fine-grained access controls, which were added in the enterprise version. Those who want to get more involved can open issues or PRs on their GitHub repo or chat on their Discord channel.
