RDB and AOF, the durability dial.

RDB writes a compact point-in-time snapshot of the whole dataset by forking a child that serializes memory to disk. It is fast to load and small on disk, but a crash loses everything written since the last snapshot — minutes of work, not seconds. AOF appends every keyspace-changing write to a log; on restart the log replays to rebuild the dataset. With a once-a-second fsync, a crash loses at most about a second.

For a cache, RDB’s snapshot-interval loss is fine. For a job store it is silent data loss: a job that was enqueued and acknowledged, then lost in the gap before the next snapshot. So valkey.conf makes AOF the single source of durability and turns RDB off.

RDB

a fork-and-serialize snapshot — fast load, small file, but loses a whole interval on a crash.

AOF

a write-by-write log replayed at startup — with everysec, a crash loses about one second.

The real config, from infra/valkey/conf/valkey.conf — the block that fronts the codemojex queue:

Line by line:

• appendonly yes turns the append-only file on — every write that changes the keyspace is appended to a log on disk.
• appendfsync everysec flushes that log to disk once a second on a background thread. The worst-case loss bound after a crash is about one second of writes — not a whole snapshot interval, and the fsync stays off the command thread.
• save "" disables RDB snapshotting. With AOF as the single durability mechanism there is no reason to keep a second snapshot fork competing for the machine. One fork source, not two.
• aof-use-rdb-preamble yes lets the periodic rewrite start from a compact RDB-format preamble rather than replaying every command, so the rewrite is fast and the file stays small — RDB’s fast load with AOF’s low loss.
• auto-aof-rewrite-percentage 100 / auto-aof-rewrite-min-size 64mb trigger that rewrite when the log has doubled and is at least 64 MB, keeping the file from growing without bound.
• propagation-error-behavior panic fails a write rather than acknowledge data that may not survive. A false acknowledgement is worse than a visible error: the caller that hears OK stops worrying about the job.

The config’s own load-bearing comment names why the persistence work has to stay off the command thread: “command execution is single-threaded, so the second shared vCPU is reserved for background work — AOF fsync, fork copy-on-write.” The once-a-second appendfsync and the rewrite fork both run on that second vCPU; the one command thread keeps serving. This is why save "" matters beyond avoiding duplicate work: a second snapshot fork would contend for the same background budget the AOF fsync needs.

Durability has a second failure mode besides a crash: memory pressure. maxmemory-policy noeviction makes a write that would exceed maxmemory return an error to the caller instead of evicting a key. For a queue, an evicted key is silently lost work — a job something already enqueued, gone. noeviction turns memory pressure into a rejected write and an alert, the loud failure R7.01 requires of a record of truth. (R8.01’s dive 3 takes noeviction apart at length; here it is the tie that makes the persistence policy a record-of-truth policy.)

The real valkey.conf makes AOF the single source of durability: appendonly yes logs every write, appendfsync everysec bounds crash loss to about a second on a background thread, save "" retires RDB so one fork serves, aof-use-rdb-preamble yes keeps the rewrite fast, and propagation-error-behavior panic refuses a false acknowledgement. That is the engine-level half of operating the bus as a record of truth — distinct from R8.01’s kernel half. Next, the same record under load: how the connector pool is sized for a single-threaded server.