When monerod syncs, it downloads and checks blocks from other nodes. But its database also needs to sync: changes held in memory must reach persistent storage. The db-sync-mode setting controls that second job. It affects disk performance and recovery after a crash.
A faster setting can shorten the initial blockchain sync. The trade-off is a greater risk of losing recent progress if the machine loses power.
Reading the database sync setting
Monero defines the option in three parts:
mode:flush-method:threshold
For example:
db-sync-mode=fast:async:250000000bytes
Here, fast selects the database write policy, async schedules flushing in the background, and 250000000bytes sets a threshold based on processed block data. That is approximately 250 MB, not an exact count of physical disk writes.
Thresholds can also use blocks, such as 1000blocks. They measure work processed, not elapsed time. Larger thresholds reduce flush frequency but leave more recent work exposed between flushes.
Safe: prioritize durable writes
With safe, monerod uses LMDB's normal durable transaction commits. A committed database transaction is flushed to storage before completion, assuming the operating system and hardware honor those requests.
The benefit is better protection against losing committed work during a system crash. The drawback is waiting for storage, which can noticeably slow initial synchronization on disks with high write latency.
The official configuration guide gives this example:
db-sync-mode=safe:sync
In monerod's parser, choosing safe makes the remaining flush method and threshold irrelevant. Durability comes from database commits, so adding a larger threshold does not turn safe mode into batched flushing.
Fast: fewer waits for storage
fast skips LMDB's normal flush at each commit and relies on later flushing. This can improve throughput while processing the blockchain.
The trade-off is crash recovery. Recent progress may disappear after a power loss or operating system failure. Depending on filesystem behavior, database corruption is also possible. LMDB documents these conditions, so “fast” should not be read as a guarantee that recovery only requires downloading a few blocks.
Fastest: more aggressive writes
fastest adds writable memory mapping and asynchronous mapping flags to the relaxed write policy. These LMDB flags used by Monero can reduce overhead, but writable mapping also exposes the database to accidental writes from application bugs.
A crash can lose recent changes or corrupt the database. Any speed improvement depends on the machine and workload. Rebuilding a damaged database can take longer than the time saved.
Sync versus async
For fast and fastest, sync performs the scheduled flush in the processing path. async dispatches it to a background worker. Both still use storage, and neither makes unfinished writes survive a power cut. The flush implementation shows this distinction.
For example, this requests a blocking flush after a threshold of 1,000 processed blocks:
db-sync-mode=fast:sync:1000blocks
A database transaction can contain several blocks. Safe mode therefore does not necessarily mean a separate physical flush for every block. Likewise, a threshold is checked around processing batches, so it is not an exact boundary.
The examples belong in the configuration file loaded by our node. For a command-line override, use --db-sync-mode=safe:sync. Check monerod --help for the installed version, and check the service configuration for an existing override before assuming the default behavior is active.
What should we use?
For most nodes, we would leave the option unset. The default is fast:async:250000000bytes, and monerod can switch to safer writes once synchronized. Explicitly setting the option disables that automatic switching, even when we copy the default value exactly.
Choose safe when avoiding lost work matters more than initial sync speed. Consider faster overrides only when the recovery cost is acceptable. Stop monerod cleanly before restarting with a changed configuration.
Pruning controls how much blockchain data we retain. fast-block-sync uses embedded historical block hashes to accelerate verification. Neither is a database flush mode. Once our node catches up, we can connect a wallet without changing these settings.