dbcache

dbcache is the Bitcoin Core option, set with -dbcache=<n> in MiB, that controls how much memory the node devotes to the chainstate (UTXO) database before flushing it to disk. Despite the name, it is less a read cache and more a write buffer: instead of writing every UTXO change to disk as it processes each block, the node accumulates changes in memory and flushes them in large batches. Because disk I/O is the bottleneck during validation — every input spent must look up and delete a UTXO, every output created must add one — a bigger dbcache dramatically reduces the time to complete the initial block download (IBD).

Defaults and trade-offs

The default is 1024 MiB on machines with at least 4 GiB of RAM, dropping to 450 MiB on smaller systems; the minimum is 4 MiB. Operators syncing a fresh node often raise it to several gigabytes temporarily — large enough to hold most of the working UTXO set in memory — which can cut sync time from days to hours on modest hardware, then lower it afterward, since the cache mainly earns its keep during bulk validation rather than steady-state operation. There is a sharp edge to respect: set it too high relative to physical RAM and the operating system starts swapping, which is far slower than a modest cache, and on a memory-starved machine the out-of-memory killer may simply terminate bitcoind mid-sync. Note also that dbcache is a target for one subsystem, not a hard cap on the process — mempool, peer buffers, and indexes have their own budgets on top.

What flushing means for your SSD and your uptime

When the cache fills (or the node shuts down cleanly), the accumulated state is written out in one large batch. This batching is friendlier to flash storage than millions of tiny writes, but it has an operational consequence: a node running with a huge dbcache holds hours of un-flushed progress in RAM, and a power cut or hard kill means that progress must be redone — in the worst cases the database is left in a state requiring a reindex. If your node runs somewhere power is unreliable, a moderate cache plus clean shutdowns beats a giant cache you might lose. Graceful shutdown (bitcoin-cli stop) always flushes; yanking the plug does not.

Practical guidance for node runners

For the sovereign node runner, dbcache is the single highest-leverage knob for first sync. A sensible recipe: during IBD, give it as much as your machine can spare while leaving comfortable headroom for the OS and mempool (on an 8 GiB machine, 4096 MiB is a common choice); after sync completes, drop back to the default and restart. If you see sustained swap I/O while bitcoind runs, restart with a lower value and consider trimming -maxmempool or connection count. On constrained hardware like a single-board computer, a balanced dbcache plus a fast SSD matters far more than raw CPU — validation is an I/O problem long before it is a compute problem. Related node-internals topics include reindex and mempool persistence.

One last clarification prevents a common misunderstanding: dbcache changes how fast your node validates, never what it validates. Every signature check, every consensus rule, every UTXO lookup happens identically whether the cache is 450 MiB or 8 GiB — the setting only decides how often intermediate state touches the disk. That makes it one of the rare tuning knobs a node runner can turn aggressively without trust trade-offs, in pleasant contrast to shortcuts like syncing from a snapshot someone else validated. Patience plus RAM buys speed; the verification is never negotiable.