InfluxData released influxdb3-client, a new async Rust client for InfluxDB 3 Core and Enterprise, mirroring the feature set of the existing official Go and Python clients with an idiomatic Rust API. It targets edge gateways, embedded systems, and high-throughput ingest pipelines where Rust already runs, such as PLC bridges, satellite ground segments, and robotics telemetry. The client supports line protocol, Point builders, and Polars DataFrame writes, SQL and InfluxQL queries returning native Arrow RecordBatches, streaming for large results, configurable retry with backoff, and backpressure controls like batch_size and max_inflight. As of version 0.2, writes default to the V2 /api/v2/write endpoint so the same binary works against InfluxDB 3 Core/Enterprise as well as Clustered and Cloud Dedicated/Serverless, with V3-only extras like no_sync available via a config flag. It requires Rust 1.89 or later and is available on crates.io.
Table of contents
Why Rust, when Go and Python clients already exist?InstallationConfiguring a clientWriting dataQuerying dataPolars integrationFAQTry itQuestions this post answers
Is there an official Rust client for InfluxDB 3?
Yes, InfluxData released influxdb3-client, an async Rust client for InfluxDB 3 Core and Enterprise that mirrors the feature set of the official Go and Python clients. It requires Rust 1.89 or later, is available on crates.io, and supports line protocol, Point builders, SQL/InfluxQL queries returning Arrow RecordBatches, and an optional polars feature for DataFrame workflows. Rust developers picking a database client can track new library releases like this one on daily.dev.
Does the influxdb3-client Rust library write to InfluxDB 3 using the V2 or V3 API by default?
As of version 0.2, writes default to the V2 /api/v2/write endpoint, meaning the same client works unchanged against InfluxDB 3 Core, Enterprise, Clustered, and Cloud Dedicated/Serverless. Setting write_use_v2_api(false), or INFLUX_WRITE_USE_V2_API=false in the environment, opts into the V3 endpoint and unlocks V3-only behaviors like no_sync() and partial-write reporting. Engineers tuning database write paths can follow API default changes like this via daily.dev.
How do I write high-throughput sensor data to InfluxDB 3 from Rust without running out of memory?
Use the influxdb3-client write builder's batch_size and max_inflight options to cap points per HTTP request and concurrent in-flight requests, since large inputs are split into batches with only one batch buffer held in memory at a time. Wrap the Client in an Arc, spread chunks across tokio tasks, and cap concurrency with a Semaphore; on the V3 endpoint, no_sync() trades durability for speed by acknowledging before the WAL syncs. Developers designing ingest pipelines can find practical Rust patterns like this through daily.dev.