InfluxDB

InfluxDB 3 Core is a high-performance, open-source time-series database engineered for collecting, processing, and storing high-volume metrics, events, and sensor data. Its diskless architecture writes directly to Parquet files on object storage — eliminating external dependencies like etcd or PostgreSQL — while delivering sub-10ms last-value query response times and sub-30ms metadata queries, making it a natural fit for real-time dashboards and alerting systems.

Built from the ground up in Rust with Apache Arrow and DataFusion as the query engine, InfluxDB 3 Core supports SQL, InfluxQL, and FlightSQL simultaneously. It maintains full backward compatibility with InfluxDB 1.x and 2.x write and query APIs, allowing existing clients and pipelines to continue without modification. An embedded Python VM enables in-database triggers and plugins written in Python, enabling data transformation, alerting logic, and custom enrichment without external stream processing infrastructure.

InfluxDB 3 Core became generally available in April 2025 and ships as Docker images, Debian and RPM packages, and tarballs for Linux, macOS, and Windows. The database is dual-licensed under MIT and Apache 2.0, making it suitable for commercial self-hosting with no licensing friction. An InfluxDB 3 Enterprise tier extends the core with additional clustering and management features for organizations that need higher availability.

The project is actively maintained by InfluxData with frequent release cadence across both the v2.x (Go-based) and v3.x (Rust-based) branches, and a thriving Discord community for support and feature discussion.

What You Get

• Diskless Parquet architecture — Data is written as Apache Parquet files directly to object storage (S3, Azure Blob, GCP, or local disk) with no requirement for external metadata stores, reducing operational complexity significantly.
• Sub-10ms last-value queries — The query engine is optimized for time-series read patterns, returning the most recent value for a metric or tag in under 10ms and metadata queries in under 30ms.
• Embedded Python plugin engine — A built-in Python VM allows you to write WAL-triggered plugins and scheduled triggers in Python for data transformation, alerting, and enrichment without deploying a separate stream processor.
• Multi-generation API compatibility — Accepts line protocol writes and InfluxQL queries from InfluxDB 1.x clients, v2 API writes from InfluxDB 2.x clients, and SQL over HTTP and FlightSQL from modern query tools — all from one running instance.
• SQL and InfluxQL query support — Query data using standard SQL, the InfluxQL DSL familiar from InfluxDB 1.x, or Apache Arrow Flight SQL for integration with modern analytics clients and notebooks.
• Zero-dependency single binary — InfluxDB 3 Core ships as a single statically linked binary with no runtime dependencies, making it straightforward to run in Docker containers, VMs, or bare metal without orchestration overhead.

Common Use Cases

• IoT sensor monitoring — Engineers ingest data from thousands of sensors using line protocol over HTTP, then query the latest readings per device in under 10ms to power real-time dashboards and threshold-based alerting.
• Server and infrastructure telemetry — DevOps teams send CPU, memory, and network metrics from Telegraf agents into InfluxDB, then visualize fleet health in Grafana using InfluxQL or SQL without deploying a separate metrics aggregator.
• Financial time-series analytics — Quantitative analysts store tick-level market data as Parquet on object storage, then run SQL aggregations over historical windows to back-test trading strategies with efficient columnar access.
• Application performance monitoring — SREs track HTTP request latency, error rates, and throughput, using InfluxDB’s last-cache queries to power interactive UI widgets that update within 10ms on each page refresh.
• In-database stream processing — Data engineers write Python plugins that fire on incoming WAL entries to validate, transform, or route data — replacing a separate Kafka consumer or Lambda function with logic that runs inside the database process.
• Network telemetry and observability — Network operations teams ingest SNMP and flow data via Telegraf, correlate interface errors with traffic spikes using SQL window functions, and set up Python triggers that page on-call when thresholds are exceeded.

Under The Hood

Architecture InfluxDB 3 Core is a Rust monorepo organized as a cargo workspace of purpose-built crates that enforce strict boundaries: the WAL buffers incoming writes in memory and flushes them as immutable Parquet files to object storage; the catalog tracks schema and table metadata in a versioned, event-driven log; the write buffer manages in-flight data until Parquet persistence completes; and the query executor uses DataFusion’s logical and physical planning pipeline to serve SQL and InfluxQL requests from a unified catalog-aware table provider. A single unified HTTP and gRPC service layer routes both write and read traffic without duplication, and the processing engine listens for WAL notifications to trigger Python plugins asynchronously. Trait-based abstractions for the WAL, write buffer, and query executor allow each layer to be tested independently and swapped without architectural disruption.

Tech Stack The primary implementation language is Rust using async/await with Tokio for the async runtime. Apache Arrow and DataFusion 51.x power columnar in-memory processing and query planning, with the Apache Parquet crate providing the on-disk format. Object storage is abstracted via the object_store crate, supporting S3, Azure Blob Storage, GCP, and local filesystem uniformly. Embedded Python scripting is provided by pyo3 0.28 with experimental async support. The HTTP layer uses Hyper 1.x and hyper-util, TLS is handled by tokio-rustls backed by the Ring cryptography library, and gRPC is implemented via Tonic with prost-generated protobuf types. CI runs on CircleCI with cargo clippy, cargo deny for dependency auditing, and insta for snapshot testing.

Code Quality The codebase maintains extensive test coverage across more than three hundred test files, combining unit tests within each crate, integration tests, and snapshot tests via the insta library to lock in parser and query planner behavior across changes. Error handling uses thiserror for typed, structured error enums in every crate rather than anyhow-style opaque errors at crate boundaries, which aids debugging and API stability. A deny.toml policy bans problematic dependencies including openssl-sys and enforces security-sensitive choices. Clippy configuration in clippy.toml enforces idiom consistency. The catalog uses a versioned migration system with explicit upgrade paths, and the WAL uses CRC-validated serialized entries, demonstrating attention to data durability and correctness at the storage layer.

What Makes It Unique The most distinctive capability is the embedded Python VM that fires synchronously on WAL entries, enabling in-database computation without an external stream processor — a pattern uncommon in any time-series database, let alone one optimized for sub-10ms queries. The diskless storage model, where neither Parquet persistence nor catalog state requires an external coordination service, sharply reduces operational surface area compared to InfluxDB 2.x and competitors that require etcd or PostgreSQL sidecar processes. The simultaneous support for three API generations (v1 InfluxQL, v2 write API, and v3 FlightSQL/SQL) from a single Rust binary makes InfluxDB 3 Core one of the few databases that can serve as a drop-in upgrade for a legacy deployment while also exposing a modern Arrow-native query interface.

Self-Hosting

InfluxDB 3 Core is dual-licensed under the MIT and Apache 2.0 licenses at the user’s choosing. Both licenses are permissive, meaning you can use, modify, and redistribute the software — including for commercial purposes — without any copyleft obligations. There are no BSL restrictions, no non-compete clauses, and no requirements to publish your modifications. This puts InfluxDB in the same licensing category as projects like Rust itself and Apache Kafka, and is explicitly chosen to distinguish it from the more restrictive BUSL or SSPL licenses adopted by some database vendors in recent years.

Running InfluxDB 3 Core in production requires planning around a few operational realities. The database is a single-process binary, so horizontal scaling and replication at the storage layer depend on your object storage provider rather than InfluxDB itself. You are responsible for configuring object storage buckets, managing authentication tokens (with optional hashing since v2.8), setting retention periods, and handling upgrades — which sometimes involve WAL format changes that need a clean shutdown procedure. The database exposes Prometheus metrics and logs via the observability stack, but setting up dashboards, alerts, and on-call workflows for the database itself falls to your team.

InfluxData offers InfluxDB 3 Enterprise as a paid tier that adds multi-node clustering, high availability, role-based access control, and managed upgrade support on top of the Core foundation. For teams that need guaranteed SLAs, support contracts, or cloud-managed hosting without the overhead of self-operating object storage pipelines, InfluxData Cloud provides a fully managed version billed by usage. Self-hosters on Core get the full query and ingestion feature set but forgo vendor-managed backups, automated failover, and direct engineering support — trade-offs that are well-documented in InfluxData’s own getting-started guides.