How realtime works? #

Do you like to let your customer wait? #

A document written to Pizza is searchable the moment its write is acknowledged — there is no refresh, no near-real-time window, and nothing to tune to get there. This page walks the write path that makes that true.

The write path #

1. WAL first. The write is appended to the shard’s write-ahead log (a local file-based WAL by default; a Kafka-backed WAL is available). Durability follows wal.local.durability — strict fsyncs per append, batched (the default) group-commits by size and timeout, async skips the hot-path fsync entirely.
2. Mutable layer. The live documents are indexed into the shard’s in-memory mutable layer, which is itself searchable — this is what removes the refresh: reads see the mutable layer and the immutable segments in one snapshot, so the visibility point is the write’s acknowledgement.
3. Epoch freeze and build. When the active epoch crosses a size or ops threshold (wal.local.epoch_freeze_max_bytes / epoch_freeze_max_ops, runtime-tunable), it is frozen and built in the background into an immutable FIRE segment. The build does not gate reads or writes.
4. WAL purge. Once a segment is durably built (per wal.local.segment_durability), the WAL entries it supersedes are purged, bounded by the retention window (wal.local.retention_epoch / retention_bytes).

Recovery is the mirror image: on restart, a shard replays its WAL tail over its last durable segments, so acknowledged writes survive crashes. Restart replay and peer recovery are both bounded by node.recovery_concurrency.

Partial updates without rebuilds #

A regular partial update is a read-modify-write guarded by optimistic concurrency control: the fetch reads the document with its version and the write back is a conditional replace, retried up to retry_on_conflict times when a concurrent write intervened.

Fields declared "inplace": true in the schema skip that machinery entirely — they live in dedicated typed columns, and an ops-only update becomes an O(1) in-place column write on the fast lane:

• No fetch/merge/re-index of the document; operators (incr, toggle, max, …) apply atomically inside the engine.
• Values are visible the moment the column write lands — a search snapshot pins the document set, not the values.
• Durability is preserved: every fast-lane update is covered by the WAL (as absolute post-update values) and periodically mirrored to .inplace checkpoint files (inplace.checkpoint_interval_ms), so replicas and restarts both recover the exact values.

See In-place columns for hot counters and flags for the full contract.

Replication #

Primaries replicate writes to their followers — full documents on the regular path, and for fast-lane inplace updates at the value level: the primary ships each operator’s resulting absolute values, and each replica applies them directly to its own columns. The delivery is idempotent (a duplicate replay of the same values is a no-op), and a replica that cannot take the fast lane falls back to applying the update through its own engine. Read more in Partial update a document.