Documentation

Monitor the performance upgrade preview

Performance preview beta

The performance upgrade preview is available to InfluxDB 3 Enterprise Trial and Commercial users as a beta. These features are subject to breaking changes and should not be used for production workloads.

InfluxDB 3 Enterprise provides system tables and a query telemetry endpoint to monitor file status, query execution, and overall performance when using the performance upgrade preview.

System tables

The upgraded storage engine exposes internal state through system tables that you can query with SQL.

system.pt_ingest_wal

View WAL files and their shards:

SELECT * FROM system.pt_ingest_wal;

Example output:

wal_file_idshard_start_timeshard_duration_secondsmin_timemax_timerow_countsize_bytesis_merged
12024-01-01T00:00:00Z864002024-01-01T00:00:00Z2024-01-01T00:10:00Z500002456789false
22024-01-01T00:00:00Z864002024-01-01T00:10:00Z2024-01-01T00:20:00Z480002345678false

InfluxDB 3.10: The system.pt_ingest_wal schema was updated to replace partition_id, database_id, and table_id with shard_start_time, shard_duration_seconds, and is_merged.

Use this table to monitor:

  • WAL accumulation: Track the number and size of unmerged WAL files
  • Shard distribution: See how data is distributed across shards
  • Time coverage: Verify data time ranges
  • Merge status: Identify WAL files where is_merged is false

Monitor WAL backlog

Check for WAL accumulation that may indicate merging is falling behind:

SELECT
  COUNT(*) as wal_file_count,
  SUM(size_bytes) / 1024 / 1024 as total_size_mb,
  MIN(min_time) as oldest_data,
  MAX(max_time) as newest_data
FROM system.pt_ingest_wal;

system.pt_ingest_files

View Gen0 files with metadata:

SELECT * FROM system.pt_ingest_files;

Example output:

file_idgenerationmin_timemax_timerow_countsize_byteshas_bloom_filter
102024-01-01T00:00:00Z2024-01-01T01:00:00Z50000045678901true
202024-01-01T01:00:00Z2024-01-01T02:00:00Z48000043567890true

Use this table to monitor:

  • File counts per generation: Track compaction progress
  • File sizes: Verify files are within configured limits
  • Time ranges: Identify Gen0 files that span multiple compaction windows

Monitor file distribution

Check file distribution and compaction status:

SELECT
  generation,
  COUNT(*) as file_count,
  SUM(row_count) as total_rows,
  SUM(size_bytes) / 1024 / 1024 as total_size_mb,
  AVG(size_bytes) / 1024 / 1024 as avg_file_size_mb
FROM system.pt_ingest_files
GROUP BY generation
ORDER BY generation;

Compaction tables

The following system tables expose the state of the pacha-tree compaction subsystem.

system.pt_compaction_active_jobs

View currently running compaction jobs:

SELECT * FROM system.pt_compaction_active_jobs;

Key columns:

ColumnDescription
plan_idUnique job identifier
plan_typeJob type (for example, L0toL1)
stateCurrent job state (for example, running, queued)
shard_idShard being compacted
total_slicesTotal work units in the job
completed_slicesWork units completed so far

system.pt_compaction_ingest_nodes

View per-ingest-node compaction lag:

SELECT * FROM system.pt_compaction_ingest_nodes;

Key columns:

ColumnDescription
node_idIngest node identifier
compaction_lagHow far behind the compactor is on this node’s data
seen_lagLag between latest observed snapshot and latest compacted snapshot
deferred_snapshot_countNumber of snapshots deferred due to compaction failures

Use compaction_lag and deferred_snapshot_count as the primary health indicators. A non-zero deferred_snapshot_count means snapshots failed to compact and are accumulating; check system.pt_compaction_deferred_snapshots for details.

system.pt_compaction_nodes

View compaction node state:

SELECT * FROM system.pt_compaction_nodes;

system.pt_compaction_run_sets

View pending compaction work grouped by time window and shard:

SELECT * FROM system.pt_compaction_run_sets;

system.pt_compaction_deferred_snapshots

View snapshots that failed to compact:

SELECT * FROM system.pt_compaction_deferred_snapshots;

A growing list here indicates a persistent compaction failure. Check error_message for the root cause.

Parquet upgrade status

If you upgraded from Parquet, use these system tables to monitor migration progress.

system.upgrade_parquet_node

View per-node upgrade status:

SELECT * FROM system.upgrade_parquet_node;

Monitor this table to confirm each node reaches completed status. During the upgrade, nodes progress through detection, conversion, and finalization stages.

system.upgrade_parquet

View per-file migration progress:

SELECT * FROM system.upgrade_parquet;

Use this table to track individual file conversions during the migration. The status updates on a polling interval (default 5 seconds, configurable with --pt-upgrade-poll-interval).

Query telemetry

The query telemetry endpoint provides detailed execution statistics for analyzing query performance.

Enable query telemetry

Query the telemetry endpoint after executing a query:

curl -X GET "http://localhost:8181/api/v3/query_sql_telemetry" \
  -H "Authorization: Bearer AUTH_TOKEN"

Replace AUTH_TOKEN with your authentication token.

Telemetry response

The response includes:

FieldDescription
query_idUnique identifier for the query
execution_time_usTotal execution time in microseconds
chunksPer-chunk statistics
cache_statsCache hit rates by type
file_statsFile-level read statistics

Example telemetry output

{
  "query_id": "q_12345",
  "execution_time_us": 4523,
  "chunks": [
    {
      "chunk_id": "c_1",
      "files_scanned": 3,
      "blocks_processed": 12,
      "rows_read": 24000,
      "rows_returned": 150,
      "bytes_read": 1234567
    }
  ],
  "cache_stats": {
    "gen0_hits": 5,
    "gen0_misses": 1,
    "compacted_hits": 8,
    "compacted_misses": 2
  }
}

Performance analysis

Query performance metrics

Track these key metrics for query performance:

MetricGoodWarningAction
Cache hit rate>80%<60%Increase --pt-file-cache-size or --pt-file-cache-recency
Rows read vs returned ratio<100:1>1000:1Add more selective predicates

Ingest performance metrics

Monitor these metrics for write performance:

MetricHealthyWarningAction
WAL file count<50>100Increase --pt-wal-flush-concurrency
Gen0 file count<100>200Increase --pt-compactor-input-size-budget

Monitor with SQL

Create a performance summary query:

-- File generation summary
SELECT
  'Gen0 files' as metric,
  COUNT(*) as count,
  SUM(size_bytes) / 1024 / 1024 as size_mb
FROM system.pt_ingest_files
WHERE generation = 0

UNION ALL

SELECT
  'Compacted files' as metric,
  COUNT(*) as count,
  SUM(size_bytes) / 1024 / 1024 as size_mb
FROM system.pt_ingest_files
WHERE generation > 0

UNION ALL

SELECT
  'WAL files' as metric,
  COUNT(*) as count,
  SUM(size_bytes) / 1024 / 1024 as size_mb
FROM system.pt_ingest_wal;

Troubleshooting

High WAL file count

Symptom: system.pt_ingest_wal shows many accumulated files.

Possible causes:

  • Merge operations falling behind write rate
  • Insufficient flush concurrency
  • Object storage latency

Solutions:

  1. Increase flush concurrency:

    --pt-wal-flush-concurrency 8
  2. Increase WAL flush interval to create larger, fewer files:

    --pt-wal-flush-interval 5s
  3. Increase the WAL buffer size so each flush produces a larger file:

    --pt-wal-max-buffer-size 30MB
  4. Check object storage performance and connectivity.

High cache miss rate

Symptom: cache_stats shows >40% miss rate.

Possible causes:

  • Cache size too small for working set
  • Cache recency window too narrow
  • Random access patterns across time ranges

Solutions:

  1. Increase cache size:

    --pt-file-cache-size 16GB
  2. Extend cache recency window:

    --pt-file-cache-recency 24h
  3. Extend eviction timeout:

    --pt-file-cache-evict-after 48h

Slow compaction

Symptom: Gen0 file count continues to grow.

Possible causes:

  • Compaction budget too low for write volume
  • High write rate overwhelming compaction
  • Snapshot size too large, creating oversized Gen0 files

Solutions:

  1. Increase the compaction input size budget:

    --pt-compactor-input-size-budget 12GB
  2. Reduce snapshot size to create smaller, more frequent Gen0 files:

    --pt-snapshot-size 125MB
  3. For distributed deployments, add a dedicated compactor node:

    influxdb3 serve \
      # ...
      --use-pacha-tree \
      --mode compact

Query node lag

Symptom: Query nodes return stale data.

Possible causes:

  • Replication falling behind
  • Network latency to object storage
  • Insufficient replica concurrency

Solutions:

For a full list of replication options, see Replication (query nodes).

  1. Increase replication concurrency:

    --pt-wal-replica-steady-concurrency 8
  2. Reduce the replication polling interval:

    --pt-wal-replication-interval 100ms
  3. Increase replica queue size:

    --pt-wal-replica-queue-size 200

Was this page helpful?

Thank you for your feedback!


InfluxDB OSS 2.9.0: API tokens are hashed by default

Stronger token security in InfluxDB OSS 2.9.0 — tokens are hashed on disk by default. Existing tokens are hashed on first startup and can’t be recovered afterward. Capture any plaintext tokens you still need before you upgrade.

View InfluxDB OSS 2.9.0 release notes

Hashed tokens authenticate exactly like unhashed tokens — clients and integrations keep working.

Also new in 2.9.0:

  • Configurable backup compression
  • Restore support for backups containing hashed tokens
  • Tighter Edge Data Replication queue validation
  • Flux upgrade
  • Compaction reliability improvements

Key enhancements in Explorer 1.9

Explorer 1.9 is now available with InfluxQL support, an AI-assisted Flux to SQL converter (beta), and new live sample data simulators.

View Explorer 1.9 release notes

Explorer 1.9 includes new features and improvements that make it easier to query, visualize, and manage data.

Highlights:

  • Flux to SQL converter (beta): Convert Flux queries to SQL with an AI-assisted converter.
  • InfluxQL support: Query data with InfluxQL in the Data Explorer and dashboards, and save and load InfluxQL queries.
  • InfluxQL visualizations: Render line and bar charts from InfluxQL results with per-tag series grouping.
  • Query error history: Review a history of query errors in the query tool.
  • Live sample data simulators: Generate continuous live sample data with new bird data and signal generator simulators.

For more details, see Explorer 1.9 release notes

InfluxDB 3.10 is now available

InfluxDB 3 Core 3.10 adds an automatic catalog format upgrade, a configurable query-concurrency limit, and processing engine improvements.

Key updates in InfluxDB 3 Core 3.10:

  • Catalog format upgrade: the on-disk catalog automatically upgrades from format v2 to v3 on first 3.10 startup. Migration is one-way—back up your catalog before upgrading.
  • --max-concurrent-queries: limit concurrent queries (adjustable at runtime).
  • GET /ready endpoint for readiness probes.
  • Processing engine: cross-database queries and trigger lockdown flags.

For more information, see the InfluxDB 3 Core release notes.

InfluxDB 3.10 is now available

InfluxDB 3 Enterprise 3.10 adds automated backup and restore, row-level deletions, and user management, with an automatic catalog format upgrade and performance preview improvements.

Key updates in InfluxDB 3 Enterprise 3.10:

  • Catalog format upgrade: the on-disk catalog automatically upgrades from format v2 to v3 on first 3.10 startup. Migration is one-way—back up your catalog before upgrading.
  • Automated backup and restore (beta)
  • Row-level deletions
  • User management (authentication and RBAC) — preview
  • Performance preview improvements

Backup and restore, row-level deletions, and the performance preview require the Enterprise storage engine upgrade (opt-in beta). Beta and preview features are subject to breaking changes and aren’t recommended for production use.

For more information, see the InfluxDB 3 Enterprise release notes

Telegraf Enterprise is now generally available

Telegraf Enterprise is now generally available, along with Telegraf Controller v1.0.

Telegraf Enterprise combines Telegraf Controller, a centralized management console for Telegraf, with official support from InfluxData. Manage configurations, monitor fleet health, and operate tens of thousands of Telegraf agents from a single system.

InfluxDB Docker latest tag changing to InfluxDB 3 Core

On September 15, 2026, the latest tag for InfluxDB Docker images will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments.

If using Docker to install and run InfluxDB, the latest tag will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments. For example, if using Docker to run InfluxDB v2, replace the latest version tag with a specific version tag in your Docker pull command–for example:

docker pull influxdb:2