CONCEPT Cited by 1 source

Raft-replicated WAL as LSM WAL

Definition

Instead of maintaining a traditional file-based write-ahead log for an LSM-tree database, the Raft consensus log is used directly as the WAL. Writes replicate through a Raft group and are considered persistent once acknowledged by a majority — combining durability, ordering, and replication into a single mechanism.

This eliminates the need for a separate durability layer on local disk while gaining built-in replication for free. Failover inherits Raft's leader-election semantics: the new leader already has the full WAL locally.

Trade-offs

• Pro: Unified durability + replication; no separate WAL file management; fast failover since replicas have the log.
• Pro: Log truncation is well-defined — once a memtable flush is captured in the manifest (also Raft-replicated), older log entries can be trimmed.
• Con: Raft majority-ack adds latency vs. local fsync (acceptable for metadata workloads, potentially not for hot-path data).
• Con: Raft log size management couples WAL retention policy with Raft log compaction.

Seen in

• systems/redpanda-cloud-topics-metastore — uses Raft groups backing internal topics as the WAL for its LSM-based metadata store (Source: sources/2026-06-09-redpanda-cloud-topics-the-metastore)