InfluxDB 3 Core & Enterprise GA: The Next Generation Time Series Platform for Developers is Here

Navigate to:

After months of development, testing, and community feedback, we’re excited to announce the general availability (GA) release of InfluxDB 3 Core and InfluxDB 3 Enterprise. This release brings us closer to our vision for InfluxDB: a time series database that helps developers solve the problem of collecting, analyzing, monitoring, and acting on data across sensors, networks, servers, and applications. We view time series as a way to analyze, monitor, and act on data through time. This can take the form of pre-computed time series stored in a database, which previous versions of InfluxDB excel at, and computing time series on the fly from raw event and observational data of all kinds. InfluxDB 3 brings us closer to realizing this broader vision.

This marks the culmination of our four-and-a-half-year journey rebuilding InfluxDB from the ground up for modern time series data workloads. We undertook this significant effort to deliver three key new capabilities that have long been requested by our users and customers: infinite cardinality in their time series data, support for keeping historical data on object storage while making it available for real-time queries, and a fully featured, standards-compliant SQL query engine.

When we evaluated the solution space for bringing these new capabilities to InfluxDB, we realized this would require a significant architectural shift. The result is here today with InfluxDB 3, a modern time series platform supporting infinite cardinality, designed with a “diskless” architecture, an embedded Python VM for collecting, processing, alerting, and automating on data in real-time, and the most operationally simple clustered InfluxDB architecture we’ve ever created.

Both InfluxDB 3 Core and Enterprise are based on that same architecture and purpose-built for the future of time series data:

  • InfluxDB 3 Core is our new open source product, a high-speed, recent data engine that’s permissively licensed under MIT/Apache 2. It runs as a single process that’s easy to set up and start using right away.
  • 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 multi-node deployments.

Since launching our alpha in January and beta in March, we’ve focused on stability, performance optimization, and incorporating user feedback.

If you’re interested in downloading and using the software right away, we’ve made it easy to get started. Whether you want to explore the open source version or kick off a 30-day trial of Enterprise, there’s no need for setup calls or sales chats—just the software, on your terms.

Technical architecture: the FDAP foundation

InfluxDB 3 is built on what we call the FDAP stack: Apache Flight, DataFusion, Arrow, and Parquet. 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. DataFusion is a fully-featured 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. Every performance gain and new feature flows straight into InfluxDB 3, accelerating its maturity with each release. Parquet serves as our persistence format, which gives great compression of our 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.

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.

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.

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.

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.

InfluxDB 3 Core architecture

InfluxDB 3 Core gives developers a high-speed, recent-data engine optimized for real-time workloads. It’s designed to collect, process, and persist data to local disk or object storage while serving queries against recent data directly from RAM. This makes it ideal for real-time system monitoring, edge data transformation, streaming analytics, and sensor-based alerting—any use case where low-latency insights are critical.

Diskless Architecture

One of the most significant architectural shifts in InfluxDB 3 is the ability to operate “diskless” – using object storage (S3, GCS, Azure Blob, etc.) as the only persistence layer. While we maintain the ability to operate solely with a local disk and no object store, this architecture enables a number of features out of the box. Specifically:

  • Multi-AZ durability without complex replication
  • Separation of compute and storage
  • Stateless operation for easier deployment and scaling in Enterprise
  • Zero data migration when upgrading or moving instances
  • Fault tolerance and isolation in multi-node Enterprise deployments

All of this is paired with extensive buffering and caching to ensure that queries against recent or hot data can be served entirely from RAM without a single request to the object store. This makes it possible to deliver query response times measured in tens of milliseconds.

Improved Query Performance with the Last Value Cache and Distinct Value Cache

We’ve introduced several features in InfluxDB 3 Core (and Enterprise) to optimize common query patterns in time series data. The Last Value Cache (LVC) and the Distinct Value Cache (DVC) are built to answer queries in under 10 milliseconds, enabling responsive UIs and fast monitoring systems.

  • Last Value Cache: Configurable to keep the N most recent values for specified tag hierarchies. For example, you can instantly retrieve the latest metrics for a specific sensor, all sensors on a machine, or all sensors in a factory.
  • Distinct Value Cache: Ultra-fast lookups for tag values and series metadata, making UI dropdowns and exploratory queries responsive.

Processing Engine: an embedded Python VM

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.

This isn’t just a new feature—it simplifies the entire stack. You define the logic, and the database runs it, with no extra infrastructure or glue code—just real-time processing where your data already lives.

The Processing Engine enables:

  • Real-time data transformation and enrichment
  • Data collection and pulling data into the database
  • Custom monitoring and alerting logic
  • Data downsampling and aggregations
  • Integration with external systems
  • HTTP endpoints for custom API creation
  • Running LLM-generated Python scripts for simple automation

Execution of these plugins is based on triggers set by the user and operator. The trigger types are:

  • WAL Flush: process batches of data on write
  • Schedule: run on a configurable timer (from milliseconds to hours or days)
  • Request: bind to an HTTP endpoint for on-demand processing

You don’t need to learn a new DSL or deploy extra services. You write Python and focus on your logic. The Processing Engine handles the rest.

Built-in Plugin API

InfluxDB 3 Python plugins have a built-in API for interacting with the database. This includes the ability to write data back into the database, query the database using the full SQL engine, and an in-memory cache for keeping state across separate trigger calls.

We’ve set up a GitHub repository with InfluxDB 3 Plugin examples and will take pull requests from the community for plugins that might be useful to a broader audience. We’re looking forward to seeing what the community does with the engine and we intend to iterate quickly on its API and capabilities over the coming months.

InfluxDB 3 Enterprise

InfluxDB 3 Enterprise is our commercial offering built for high-scale production workloads. It builds on the Core engine and adds the features needed to run reliably at scale—whether supporting thousands of sensors, running long-term analytics, or powering critical infrastructure.

Enterprise includes:

  • A compactor that optimizes data layout for queries against more than an hour of data and historical queries
  • Security features enabling read and write access tokens for specific databases
  • High availability with muti-node deployments
  • Read replicas to scale out query and processing workloads
  • Workload isolation with the ability to separate and scale independently ingest, query, processing, and compaction

Enterprise is designed for operational simplicity—whether you’re running on bare metal, VMs, containers, or Kubernetes. Its diskless architecture isolates workloads and shares only object store files, making it easy to integrate into existing infrastructure and deploy at scale.

Free Tier for Home Users

For non-commercial at home or hobbyist use, we have a free Enterprise tier. It is limited to a single-node deployment with two cores. It includes the compaction engine, enabling better performance and historical time series queries.

We built this tier to give hobbyists access to a complete, production-grade time series database they can use for learning, experimentation, or personal projects. It’s a simple way to explore what’s possible with InfluxDB 3.

Migration and Compatibility

We’ve worked hard to build compatibility with as many of the previous versions of InfluxDB as possible. Specifically, we support:

  • InfluxDB 1.x and 2.x write APIs: We support the previous write APIs and InfluxDB Line Protocol
  • InfluxQL and the 1.x query API: We’ve implemented InfluxQL on top of the DataFusion query engine to enable users to query via legacy InfluxQL and a new v3 InfluxQL endpoint in addition to DataFusion’s native SQL

Schema Considerations

While InfluxDB 3 maintains the familiar measurement, tag/field data model mapped onto a more traditional SQL table model, there are some important schema considerations:

  • Tags and fields must have unique names within a measurement
  • Database limits: 5 in Core and 100 in Enterprise (with the ability to increase in configuration)
  • Table limits: 2,000 in Core and 10,000 in Enterprise (with the ability to increase in configuration)

Migration Paths

We’re developing two primary migration approaches:

  • For Enterprise Users: We’re building comprehensive data migration tools for InfluxDB Enterprise that will preserve your historical data while transitioning to the new architecture. These tools will be released in the coming months.
  • For Core Users: Since InfluxDB 3 Core is designed specifically for recent data (72 hours), our recommendation for migration is to mirror writes from older versions to a new InfluxDB 3 Core instance for a transition period, then switch over entirely after 72 hours.

For users of Flux, we unfortunately aren’t providing a direct compatibility layer at this time. However, the combination of the Python Processing Engine, SQL, and InfluxQL should provide equivalent or improved functionality for most use cases. The plugin system is the natural successor to functionality from earlier versions, including Continuous Queries, Tasks, Kapacitor, and Telegraf. While Kapacitor and Telegraf remain compatible with InfluxDB 3, the plugin model brings that functionality directly into the database.

What’s next

The general availability of InfluxDB 3 Core and Enterprise is just the first step. Together, they deliver a solid foundation for faster analytics, deeper integrations, and smarter automation. Whether you’re just getting started or already running large-scale workloads, the new engine gives the performance and flexibility to power real-time monitoring, long-term analytics, and event-driven automation at scale. And we’re just getting started—more features, plugins, and tools to build with are on the way.

If you’re new to InfluxDB, there’s never been a better time to get started. Check out our getting started guide for Core and Enterprise, and join the conversation to share feedback and help shape what’s next: