Documentation

InfluxDB 3 Core internals

How data flows through InfluxDB 3 Core

When data is written to InfluxDB 3 Core, it progresses through multiple stages to ensure durability, optimize performance, and enable efficient querying. Configuration options at each stage affect system behavior, balancing reliability and resource usage.

Data flow for writes

As written data moves through InfluxDB 3 Core, it follows a structured path to ensure durability, efficient querying, and optimized storage.

Ingest path and data flow for InfluxDB 3 Core & Enterprise Figure: Write request, response, and ingest flow for InfluxDB 3 Core and Enterprise

  1. Write validation and memory buffer
  2. Write-ahead log (WAL) persistence
  3. Query availability
  4. Parquet storage
  5. In-memory cache

Write validation and memory buffer

  • Process: InfluxDB validates incoming data before accepting it into the system.
  • Impact: Prevents malformed or unsupported data from entering the database.
  • Details: The database validates incoming data and stores it in the write buffer (in memory). If no_sync=true, the server sends a response to acknowledge the write.

Write-ahead log (WAL) persistence

  • Process: The database flushes the write buffer to the WAL every second (default).
  • Impact: Ensures durability by persisting data to object storage.
  • Tradeoff: More frequent flushing improves durability but increases I/O overhead.
  • Details: Every second (default), the database flushes the write buffer to the Write-Ahead Log (WAL) for persistence in the Object store. If no_sync=false (default), the server sends a response to acknowledge the write.

Query availability

  • Process: The system moves data to the queryable buffer after WAL persistence.
  • Impact: Enables fast queries on recent data.
  • Tradeoff: A larger buffer speeds up queries but increases memory usage.
  • Details: After WAL persistence completes, data moves to the queryable buffer where it becomes available for queries. By default, the server keeps up to 900 WAL files (15 minutes of data) buffered.

Parquet storage

  • Process: Every ten minutes (default), data is persisted to Parquet files in object storage.
  • Impact: Provides durable, long-term storage.
  • Tradeoff: More frequent persistence reduces reliance on the WAL but increases I/O costs.
  • Details: Every ten minutes (default), the InfluxDB 3 Core persists the oldest data from the queryable buffer to the Object store in Parquet format, and keeps the remaining data (the most recent 5 minutes) in memory.

In-memory cache

  • Process: Recently persisted Parquet files are cached in memory.
  • Impact: Reduces query latency by minimizing object storage access.
  • Details: InfluxDB 3 Core puts Parquet files into an in-memory cache so that queries against the most recently persisted data don’t have to go to object storage.

Was this page helpful?

Thank you for your feedback!


New in InfluxDB 3.5

Key enhancements in InfluxDB 3.5 and the InfluxDB 3 Explorer 1.3.

See the Blog Post

InfluxDB 3.5 is now available for both Core and Enterprise, introducing custom plugin repository support, enhanced operational visibility with queryable CLI parameters and manual node management, stronger security controls, and general performance improvements.

InfluxDB 3 Explorer 1.3 brings powerful new capabilities including Dashboards (beta) for saving and organizing your favorite queries, and cache querying for instant access to Last Value and Distinct Value caches—making Explorer a more comprehensive workspace for time series monitoring and analysis.

For more information, check out:

InfluxDB Docker latest tag changing to InfluxDB 3 Core

On November 3, 2025, 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