Mempool Persistence

Mempool persistence is the feature that lets a Bitcoin Core node remember its pool of unconfirmed transactions across a restart. On a clean shutdown the node serializes the current memory pool to a file named mempool.dat in the data directory, and on the next startup it reads that file back and re-loads the transactions, re-checking each one against current consensus and policy rules. Without this, every restart would empty the mempool, and the node would have to slowly relearn pending transactions from its peers.

Why it matters

A warm, well-populated mempool improves fee estimation, gives miners and wallets a realistic view of the fee market immediately after boot, and reduces redundant relay traffic. Fee estimation in particular is history-dependent: Bitcoin Core builds its estimates from watching which fee rates actually confirm and how long they wait, so a node that boots with an empty pool gives poor answers until it has observed the market again. The getmempoolinfo RPC exposes a loaded flag that stays false until the node has finished restoring mempool.dat, so tools can wait for a complete picture before trusting fee data. Persistence is controlled by the -persistmempool option, which is on by default, and the file can also be written on demand with the savemempool RPC — a sensible step before any deliberate restart.

What survives the reload — and what doesn't

Reload is not a blind restore; every transaction is re-evaluated as if it had just arrived. Transactions that have since confirmed or been conflicted by a confirmed spend are dropped. So are transactions that no longer meet current policy — including any that fall below the dynamic mempool minimum fee that rises when the pool is under memory pressure. The mempool also enforces its standing limits after reload: a default size ceiling of 300 MB (-maxmempool) and a default expiry that evicts transactions unconfirmed after two weeks (-mempoolexpiry, 336 hours). Persistence preserves the node's view; it never grandfathers anything past the rules.

Limits and caveats

Persistence only applies to a clean shutdown; a crash or power loss may leave a stale or missing file, in which case the node simply starts with an empty mempool and refills from peers — a self-healing failure, not a dangerous one. It is also worth remembering what the mempool is: each node's local, policy-filtered view, not a global data structure. Persistence keeps your view continuous, but two nodes' mempools were never guaranteed to match in the first place.

Why a sovereign node runner should care

The feature also illustrates a design habit worth noticing throughout Bitcoin Core: state that can be regenerated from the network is cached but never trusted. The mempool file is a convenience copy, revalidated line by line on load, and its loss costs only warm-up time. Contrast that with wallet keys or the chainstate, which are guarded far more carefully. Knowing which files in your data directory are precious and which are merely convenient is basic literacy for anyone administering their own node — it decides what belongs in your backup plan and what can simply be regenerated after a failure.

If your node backs your wallet, your fee decisions, or a Lightning stack, mempool continuity is part of the service quality you are self-hosting. A home node that reboots for updates and comes back already knowing the pending fee market gives you honest fee estimates minutes later rather than hours. Pair a healthy mempool configuration with sensible resource tuning — see dbcache for the sync-side equivalent — and a modest machine delivers the same quality of chain view as anyone's infrastructure, which is the entire point of running your own node.