Key details

  1. The official `influxdb:latest` Docker tag changes from InfluxDB 2 to InfluxDB 3 Core on September 15, 2026.
  2. InfluxData explicitly warns that existing deployments following `latest` can break on the next image pull.
  3. InfluxDB 2 users who are not migrating should pin `influxdb:2`.
  4. InfluxDB 3 Core is a ground-up Rust-based implementation rather than a drop-in rebuild of v2.
  5. InfluxDB 3 uses Apache Arrow/DataFusion and a different storage architecture.
  6. InfluxDB 3 supports SQL and InfluxQL.
  7. Flux is not supported in InfluxDB 3.
  8. InfluxData maintains migration and compatibility guidance for moving v1/v2 workloads to v3.
  9. The tag change affects Docker image selection; it does not itself migrate existing on-disk data safely.

What builders should take away

  1. Search deployment files, Compose files, Kubernetes manifests and automation for `influxdb:latest` and pin `influxdb:2` immediately if you are staying on v2.
  2. Do not rely on an existing running container as proof you are safe; the major jump appears when the image is next pulled or the container is recreated.
  3. If you plan to move to v3, test query compatibility, ingestion APIs, retention behavior, schema assumptions and backup/restore before changing production images.
  4. Inventory Flux queries, tasks and dashboards before migration because Flux is not supported by InfluxDB 3.
  5. Pin an explicit v3 version or digest during migration rather than moving from one floating `latest` target to another.
  6. Back up state before any major database image change and verify the documented v2-to-v3 migration path rather than mounting an old data directory into a new major engine blindly.

What changed

On September 15, 2026, InfluxData changed the official Docker `influxdb:latest` tag from InfluxDB 2 to InfluxDB 3 Core. InfluxData had pre-announced the change and explicitly warned that users who rely on the floating `latest` tag may receive an unexpected major-version jump the next time Docker pulls the image. Teams that intend to stay on the v2 line are told to pin `influxdb:2` instead. The distinction is important because InfluxDB 3 is not a drop-in rebuild of v2: it uses a new Rust/Apache Arrow/DataFusion/object-storage architecture, supports SQL and InfluxQL rather than Flux, and has separate migration and compatibility guidance for v1/v2 workloads.

Why it matters

A database container tag can be part of an automated restart, server rebuild or deployment pipeline, so a floating tag can change production behavior without a code change in the application repository. The September 15 switch turns that risk into a concrete breaking boundary. Applications that depend on Flux, v2 APIs, storage layout or operational assumptions need an intentional migration plan rather than discovering the difference after a container is replaced. Even teams already planning to adopt v3 should pin exact versions during the migration so the database upgrade is reproducible and reversible.

`latest` now means a different database generation

The Docker Official Image and InfluxData documentation now point `influxdb:latest` to InfluxDB 3 Core. A machine that previously pulled v2 from the same tag can therefore receive v3 during a recreate, image refresh or infrastructure rebuild. Pinning `influxdb:2` preserves the v2 line.

InfluxDB 3 is not a transparent v2 binary replacement

InfluxDB 3 Core is a ground-up implementation using Rust, Apache Arrow, DataFusion and object-storage-oriented persistence. InfluxData provides compatibility endpoints and migration tooling for some v1/v2 workflows, but operators should treat the move as a database migration with schema, API and query-language review rather than as an ordinary container update.

Flux users have a hard compatibility boundary

InfluxDB 3 supports SQL and InfluxQL but does not support Flux as a query language. Applications, dashboards or tasks that still depend on Flux need to stay on v2 or be rewritten before a v3 migration.

Floating tags are especially risky for stateful infrastructure

Using `latest` may be tolerable for a disposable development image, but it is a poor control point for a stateful database. An image digest or explicit version tag lets teams test the exact engine release, coordinate backups and migration steps, and avoid silently changing major versions during routine deployment automation.

What to watch next

  • Whether InfluxData changes the v2 maintenance window or publishes additional automated migration tooling.
  • How Docker/Compose users report real-world failures after the `latest` switch.
  • Expansion of v2 API compatibility in InfluxDB 3 Core.
  • Whether Flux-dependent tooling adds SQL/InfluxQL migration paths.
  • Future changes to the Docker Official Image tag policy for InfluxDB 3 releases.

Still unclear

  • The exact failure mode for a deployment following `latest` depends on its volumes, configuration, API usage and orchestration behavior; the tag switch does not imply every installation fails in the same way.
  • Compatibility endpoints cover some v1/v2 workflows but do not make InfluxDB 3 fully equivalent to v2.
  • InfluxData continues to maintain v1/v2 lines, so the Docker tag change is a default-selection change rather than an immediate end-of-support event.

Sources

Direct reading behind this dossier.

3 sources
InfluxDB 3 documentation
InfluxData primary documentation

Primary product documentation and warning about the September 15 `latest` tag transition.

InfluxDB Docker image tag migration notice
InfluxData / GitHub primary migration notice

Primary warning that `influxdb:latest` will move from v2 to v3 Core and that v2 users should pin the v2 tag.

InfluxDB Official Image
Docker primary distribution documentation

Current official-image tag guidance and migration warning.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment