influxdb-client-python: the InfluxDB 2.x client, and when to pick another one

Three client libraries, and you need the one that matches your server

The repository contains the Python client library for use with InfluxDB 2.x and Flux, and the README is explicit about the other two. InfluxDB 3.x users should instead use the lightweight v3 client library, hosted by the InfluxCommunity organisation, and InfluxDB 1.x users should use the v1 client library, influxdb-python. There is a further note for v2 users: for ease of migration and a consistent query and write experience, they should consider using InfluxQL and the v1 client library. And the API of influxdb-client-python is explicitly not backwards compatible with the old influxdb-python. So there is a version decision before there is a code decision, and the version decision is the one that is expensive to get wrong, because a client talking to the wrong server generation fails in ways that look like configuration errors.

The write side offers four shapes, and the choice is about backpressure

Writing data is supported through four different mechanisms, and picking between them is the main design decision on the write path. You can write Line Protocol, the text format InfluxDB natively speaks. You can write a Data Point object, which the README points at the Point class in the client. You can write a Pandas DataFrame, with the repository carrying an ingest_dataframe_default_tags.py example showing how default tags are applied. And you can write an RxPY Observable, which is where the reactive dependency earns its place. The client exposes a write_api obtained from the client, and the mode is chosen by the write options, with SYNCHRONOUS imported from influxdb_client.client.write_api in the getting started example. The asynchronous variants and the batching variant are separate examples, asynchronous.py, asynchronous_batching.py, import_data_set_sync_batching.py, which tells you the library treats backpressure strategy as a first-class concern rather than an afterthought.

Queries come back in four shapes, and the table form is the useful one

Querying uses the Flux language and can return csv, raw data, a flux_table structure or a Pandas DataFrame, and the README links directly to the flux_table implementation in the client. That last option is the one worth understanding. A query returns a list of tables, and each table has records, and each record has a values dictionary, so a caller that wants row-level access iterates tables and then records rather than receiving a flat list of rows. The getting started snippet in the README shows exactly that shape:

from influxdb_client import InfluxDBClient, Point
from influxdb_client.client.write_api import SYNCHRONOUS

bucket = "my-bucket"

client = InfluxDBClient(url="http://localhost:8086", token="my-token", org="my-org")

write_api = client.write_api(write_options=SYNCHRONOUS)
query_api = client.query_api()

p = Point("my_measurement").tag("location", "Prague").field("temperature", 25.3)

write_api.write(bucket=bucket, record=p)

There is a query_csv form as well, and the difference between the two is whether you want typed values or raw rows, which is a choice about what you do with the result rather than about the query itself.

The management API is generated from the swagger spec

Beyond the query and write paths, the client includes an InfluxDB 2.0 API client for management, and the README states plainly that the client is generated from the server's swagger definition using the openapi-generator. The consequence is worth spelling out. You do not hand-maintain a binding for every management endpoint, because the bindings are derived from the server's own specification, so a server that adds an endpoint is a client that gains a method. The generated surface covers organizations and users management, buckets management, tasks management, authorizations, and a health check, with the list trailing off into an ellipsis. The flip side is that this layer is not hand-tuned for ergonomics, so if you find yourself fighting the generated names, that is the design rather than a rough edge.

Configuration comes from an ini segment, environment or code

The client configuration section describes several ways to configure a client, and the file route is the one with real substance. A client can be configured via an ini file in the segment influx2, and the documented options are url for the address to connect to InfluxDB, org for the default destination organization for writes and queries, token for authorization, timeout for the socket timeout in milliseconds with a default of 10000, verify_ssl which can be set to false to skip verifying the SSL certificate when calling the API from an https server, and ssl_ca_cert to customise the certificate file. The timeout default is worth noting on its own, since 10 seconds is generous for a control plane call and a long wait for a write. There is also a section on the InfluxDB 1.8 API compatibility and a set of advanced topics covering gzip support, proxy configuration, nanosecond precision, delete data, error handling and logging.

ciso8601 is the install detail that changes performance

The README recommends using ciso8601 with the client for parsing dates, because it is much faster than the built-in Python datetime, and because it is written as a C module the best way is to build it from sources. The install section then gives three routes. The PyPI route is the simple one:

pip install 'influxdb-client[ciso]'

On Windows you need the Visual C++ Build Tools 2015 to build ciso8601 by pip, and on conda the instruction is to install from sources with conda install -c conda-forge/label/cf202003 ciso8601. The extras are declared in setup.py, with the ciso extra requiring ciso8601 at 2.1.1 or later, the extra extra pulling pandas and numpy, and the async extra bringing aiohttp and aiocsv. The client uses RxPY, the Reactive Extensions for Python, and requires Python 3.7 or later, so the async path is an install-time choice rather than something you turn on later.

A 1.x line, a Beta classifier, and a maintained repository

The maintenance picture is good. The repository is not archived and the last push was on 2026-10-22, the same day the version 1.50.0 tag was published on 2026-01-23 after 1.49.0 in May 2025 and 1.48.0 in November 2024. The licence is MIT with the LICENSE file at the root. The project runs on CircleCI with a codecov badge and a readthedocs documentation status, and the repository carries a MIGRATION_GUIDE.rst, conda/ and docker/ directories, a notebooks/ directory for the Jupyter examples, and an examples/ directory with around two dozen scripts covering asynchronous writing, batching, retries, parquet import, multiprocessing import, invokable scripts, IoT sensor ingestion and error handling. One caveat is visible in the packaging rather than the prose: the classifier says Development Status:: 4 - Beta, and the README's own recommendation to consider the v1 client for a consistent query and write experience is a sign that the v2 API surface is not entirely settled.

Editorial conclusion

Adopt influxdb-client-python if you are on InfluxDB 2.x and want Flux queries, pandas interop and an asyncio path in one package. Do not adopt it on InfluxDB 3.x or 1.x, because the README points those users at separate client libraries, and note that the API of this library is explicitly not backwards compatible with the older influxdb-python. Before you commit, install the ciso extra, since the README recommends it for date parsing speed, and decide whether your workload needs the synchronous, batching or asynchronous write API before wiring the client in.

Frequently asked questions

Official sources

1. influxdata/influxdb-client-python on GitHub
2. License: MIT
3. Project website
4. README
5. Releases