Write-Ahead Log (WAL)

In QuestDB 7.0, we added a new approach to ingest data using a write-ahead log (WAL). This page introduces the properties of a WAL-enabled table (WAL table) and compares it to a non-WAL table. It also contains a summary of key components, relevant functions, as well as related SQL keywords.


A WAL table must be partitioned. It permits the following concurrent transactions:

  • Data ingestion through different interfaces
  • Data modifications
  • Table schema changes

Enabling WAL and configurations#

The following keywords enable WAL tables:

  • WAL table creation via CREATE TABLE

  • Converting an existing table to a WAL table or vice versa via SET TYPE following a database restart.

  • Server-wide configuration via cairo.wal.enabled.default

    • When cairo.wal.enabled.default is set to true (default), the CREATE TABLE SQL keyword generates WAL tables without WAL. The BYPASS WAL keyword still works as expected.

Parallel threads to apply WAL data to the table storage can be configured, see WAL table configuration for more details.


The following table highlights the main difference between a WAL and a non-WAL table:

WAL tableNon-WAL table
Concurrent data ingestion via multiple interfacesInfluxDB Line Protocol locks the table for ingestion; concurrent data ingestion via other interfaces is not allowed - Table Busyerror
Unconstrained concurrent DDLs and DMLsConcurrent DDLs and DMLs for InfluxDB Line Protocol interface only
Asynchronous operations - in rare situations there may be slight delays in data visibilitySynchronous operations - no-wait commits
Improved data freshness for DROP and RENAME of the table with a system-wide lockNo change
Some impacts on existing operationsNo change



We are working hard to reduce the below limitations.

For a WAL table, the following existing operations may have different behaviors from a non-WAL table:

Key components#

A WAL table uses the following components to manage concurrent commit requests:

  • WAL: acts as a dedicated API for each ingestion interface. When data is ingested via multiple interfaces, dedicated WALs ensure that the table is not locked by one interface only.

  • Sequencer: centrally manages transactions, providing a single source of truth. The sequencer generates unique txn numbers as transaction identifiers and keeps a log that tracks their allocation, preventing duplicates. This log is called TransactionLog and is stored in a meta file called _txnlog. See root directory for more information.

  • WAL apply job: collects the commit requests based on the unique txn numbers and sends them to the TableWriter to be committed.

  • TableWriter: updates the database and resolves any out-of-order data writes.

Diagram showing the sequencer allocating txn numbers to events cronologically
The sequencer allocates unique txn numbers to transactions from different WALs chronologically and serves as the single source of truth.
Diagram showing the WAL job application and WAL collect events and commit to QuestDB
The WAL job application collects the transactions sequencially for the TableWriter to commit to QuestDB.

Checking WAL configurations#

The following table metadata functions are useful for checking WAL table settings:

โญ Something missing? Page not helpful? Please suggest an edit on GitHub.