Skip to content
TrustMyStack, home

influxdb

v3.12.2
influxdata/influxdb

Scalable datastore for metrics, events, and real-time analytics

Version of influxdata/influxdb you run

CompareView on GitHub
Maintenance
Active27 commits in 3 months · bus factor 12
License
Apache-2.0Permissive · OSI-approved
Security
No advisories publishedScorecard 6.2/10
Supported versions
3 lines supportednewest 3.12 · oldest 3.10 · 9 ended

31.8k stars · 3.8k forks · 2.2k open issues · last release 12 days ago · data checked 2 hours ago

OverviewTourReleasesDocker imagesSecurityLogos

Supported versions

Source: endoflife.date
LineLatestReleasedSecurity fixes
3.123.12.2Oct 2, 2026Supported
3.113.11.8Jul 30, 2026Supported
3.103.10.6Jun 17, 2026Supported
3.93.9.13Apr 2, 2026Ended Jul 30, 2026
3.83.8.3Dec 18, 2025Ended Jun 17, 2026
3.73.7.0Nov 19, 2025Ended Apr 2, 2026
3.63.6.0Oct 30, 2025Ended Dec 18, 2025
3.53.5.0Sep 29, 2025Ended Nov 19, 2025
3.43.4.2Aug 26, 2025Ended Oct 30, 2025
3.33.3.0Jul 29, 2025Ended Sep 29, 2025
3.23.2.1Jun 25, 2025Ended Aug 26, 2025
3.13.1.0May 28, 2025Ended Jul 30, 2025

Breaking changes

What to check before upgrading, taken from the notes of the last 30 releases.

  • v3.12.0Oct 15, 2026

    Breaking changes

    • Finite default for --max-concurrent-queries: The --max-concurrent-queries default is now the larger of 50 and 4 times the node's query parallelism. Previously, the default was effectively unlimited. Queries over the limit wait for a slot instead of failing. An explicit value below 16, or below the node's query parallelism, logs a startup warning.
    • WAL buffer limit enforced: --wal-max-buffered-writes (default 100000) was never enforced. When the WAL buffer is full, writes now return 429 Too Many Requests, so retry them after a short delay. On Enterprise, this applies to the Parquet engine.
    • HTTP and gRPC request metrics split by protocol: http_requests* metrics now count only HTTP requests, and grpc_requests* metrics count only gRPC requests. Previously, both counted every request, so dashboards that sum the two families will show lower values. The path and method_path labels now use route templates, such as /api/v3/engine/:path. Unrecognized paths are reported as other. Panels that filter on a literal path that includes an ID return no data.
    • DataFusion 52.5: The query engine is upgraded from DataFusion 51.0 to 52.5. pow() and power() with integer arguments now return a float.
    • New system table columns: system.databases adds a schema_mode column at the end. system.nodes adds conn_info, and system.tables adds retention_period_ns, both before existing columns, so the column order of SELECT * on those tables changes.
  • v3.11.2Sep 8, 2026

    Breaking changes

    • --l1-hot-tail-target-size is functional again: The option (default 250mb) caps live L1 tail rewrites during snapshot compaction, and a larger tail is handed to L1 consolidation to seal. It was previously accepted and ignored.
    • --l1-consolidation-min-age and --row-delete-max-jobs-per-tick are now ignored: L1 consolidation has no age gate, and row-delete work shares the weighted delete slot. Both options are still accepted.
    • --l1-consolidation-target-size is now the established-L1 size boundary: Consolidation consumes run sets at or below it, and promotion requires at least two L1 run sets larger than it. --l1-consolidation-min-run-sets and --compactor-max-source-run-sets-per-promotion now apply only to the legacy layout.
    • --replica-snapshot-manifest-load-concurrency applies to both storage engines: It now bounds the boot-time snapshot manifest load on the Parquet engine as well as the upgraded engine. When unset, each engine derives its own default.
    • Compactor status log fields changed: The service_memory_* fields are gone, and pending_input_mb is renamed to charged_input_mb.
  • v3.10.0Jun 17, 2026

    Breaking Changes

    • Catalog v3 migration is one-way: Back up your catalog before upgrading (see above).
    • --pt-partition-count renamed to --pt-shard-count; there's no alias, so update startup scripts.
    • /api/v2/write returns 403 (was 401) for valid tokens lacking write permission; line-protocol parse errors now return 400 (was 500).

    Bug Fixes

    • Compaction stability improvements (ingest-time, deadlock/write-amplification, gen1 orphaning, and upgrade-blocking fixes), plus several other bug fixes and performance improvements.
    • Many other bug fixes and performance improvements

    Full Changelog: https://github.com/influxdata/influxdb/compare/v3.9.3...v3.10.0

Release history

All releases on GitHub
Atom feed/feed/influxdata/influxdb
BadgeLatest version of influxdata/influxdb[![version](/badge/influxdata/influxdb)](/p/influxdata/influxdb)

v3.12.2 | 10-29-26

The following are some highlighted updates with the newest release for InfluxDB 3. Learn more via our full Release Notes.

Updates

Core

Features

  • influxdb3 debug catalog repair: This offline command, added in v3.11.6, is now also available on 3.12.2. It repairs a catalog that fails to load because of a duplicate table name or a reused table or database ID. Stop every node before you run it with --execute.
  • Processing engine Python updated to 3.13.18: Picks up the security fixes released since 3.13.15.

Bug fixes

  • Queries that exceed memory limits returned 500: The HTTP query endpoints now return 429 Too Many Requests when a query exhausts the DataFusion memory pool. Previously, they returned 500. For CSV, JSON, and JSON Lines output, this applies when the query fails before it returns any rows. An error after the first rows still ends the HTTP 200 response early. Some Core queries still return 500, such as a query on a table that runs out of memory while deduplicating data. Enterprise already mapped resource-exhaustion errors to 429.
  • Catalog deadlock when checking a deleted table: Checking whether a table is deleted now takes the catalog lock once. Previously, a catalog change that arrived between its two reads could deadlock the catalog.
  • WAL plugins received values under the wrong column names: Rows passed to a WAL trigger's plugin now use the column names of their own record batch. Previously, when a flush held batches with the same columns in a different order, later batches used the first batch's column names.
  • Other bug fixes and performance improvements

Enterprise

All Core updates are included in Enterprise.

Additional Enterprise-specific updates:

Features

  • Faster file index loading (Parquet engine): Loading a table's file index, including during a storage engine upgrade, now sorts each posting list once. Previously, every generation re-sorted each list it touched, so a table with many generations loaded slowly and used more memory.
  • Faster reads of compaction metadata (Parquet engine): Compaction and snapshot metadata files are now parsed in one pass, including during a storage engine upgrade. Previously, each was parsed twice.
  • Table index cache starts once the server is ready (Parquet engine): On ingest nodes, the table index cache now starts its background work when the server reports ready, instead of at the beginning of startup.
  • Fewer file downloads per query (upgraded storage engine): A query now downloads only the run set files whose key range covers the queried field family. Previously, it also downloaded files that held only the table's other field families.
  • Faster merging of overlapping files (upgraded storage engine): When a query merges rows from several files, each output column is now built in one vectorized step instead of row by row.

Bug fixes

  • Storage engine upgrade completed with unconverted Parquet files: If a Parquet file fails every conversion attempt, the ingest node now reports failed in system.upgrade_parquet_node. The last_message column identifies the file and its error. The cluster upgrade also fails. To resume the upgrade, follow the retry procedure. Previously, the node dropped the file and reported its upgrade as complete.
  • Storage engine upgrade stalled after an ingest node was removed: The upgrade now drops a removed ingest node from its roster once its Parquet files are converted or absorbed. Previously, a removed ingest node held the cluster at upgrading forever.
  • Overwrites lost after a query node restart (upgraded storage engine): After a restart, a query node now reads gen0 files in the order they were written, so the latest write to a series and timestamp wins. Previously, a query could return the value from before an overwrite until compaction.
  • Query node could miss writes from a stopping ingest node (upgraded storage engine): A query node now keeps following an ingest node that is stopping and fetches its remaining WAL files after it acknowledges the stop. Previously, the query node could stop fetching before the node flushed its last writes.
  • Trailing WAL fetch could hang after an ingest node stopped (upgraded storage engine): A query node's fetch of a stopped ingest node's remaining WAL files now completes. Previously, it could wait forever on files its workers had already fetched.
  • Nodes stopped applying compaction updates after falling behind (Parquet engine): A node that refreshes its view of compacted data no longer reads the detail of each generation the compaction removed. Previously, a node more than --compaction-cleanup-wait behind the compactor failed every refresh with generation detail not found until it restarted.
  • Retention stopped after Gen1 file cleanup deleted a snapshot (Parquet engine): The table index cache now skips a snapshot that Gen1 file cleanup already deleted. Previously, the missing snapshot failed the cache initialization, and retention didn't run until the next restart.
  • Restarted node listed as stopped by its previous process: A process that is shutting down no longer marks its node stopped once another process has registered under the same --node-id. Previously, a slow shutdown could mark the running replacement as stopped, and on the upgraded storage engine query nodes stopped following its WAL.
  • Schema changes lost when upgrading a Core node to Enterprise: Upgrading from Core now promotes the node's live catalog. Previously, if the Core node had first run a release before 3.10, the upgrade promoted a stale catalog checkpoint, so schema changes made since then were missing.
  • Other bug fixes and performance improvements

Full release notesCompare with previous