Bitcoin Core v31 Will Default to 1 GB Database Cache | Bitcoin Index

Bitcoin Core just merged a change that will make new nodes sync noticeably faster. Pull request #34692, merged March 6 by maintainer achow101, increases the default database cache from 450 MB to 1 GB for systems with at least 4 GB of RAM.

This is only the third time Bitcoin Core has adjusted this default in its history. The last change was in 2017, when the cache went from 300 MB to 450 MB. Nine years later, hardware has evolved, the blockchain has grown past 700 GB, and most consumer devices now ship with enough RAM to handle a larger cache without breaking a sweat.

What is dbcache?

The -dbcache setting controls how much memory Bitcoin Core keeps for the in-memory view of the UTXO (Unspent Transaction Output) set. Think of the UTXO set as the current state of the Bitcoin ledger: every unspent bitcoin that could be spent in a future transaction.

While the authoritative UTXO set lives on disk in the chainstate database, Bitcoin Core caches a portion of it in RAM for speed. A larger cache means:

Faster initial block download (IBD) for new nodes syncing the blockchain
Reduced disk I/O during block validation
Lower flush frequency (the node writes to disk less often during sync)

After initial sync, the performance benefit is less dramatic for casual use cases, though it still helps with block validation speed if you’re mining or running a high-traffic node.

How much faster?

PR #34641, an alternative proposal that included extensive benchmarking, tested reindex-chainstate performance across different hardware profiles. The data shows the jump from 450 MB to 1 GB delivers meaningful improvements across the board:

Modern laptop (Apple M4 Max, 64 GB RAM, SSD):

450 MB cache: 5h 37m
1000 MB cache: 3h 12m
1.76x speedup

Budget node hardware (Umbrel N150, 15 GB RAM, SSD):

450 MB cache: 9h 20m
1000 MB cache: 8h 19m
1.12x speedup

Raspberry Pi 5 (8 GB RAM, SSD):

450 MB cache: 52h 06m
1536 MB cache: 36h 24m
1.43x speedup

Consumer desktop (i9-9900K, 62 GB RAM, SSD):

450 MB cache: 6h 07m
2000 MB cache: 5h 05m
1.20x speedup

The exact speedup depends on your hardware, but even budget setups see a noticeable improvement. High-end machines with fast SSDs can cut sync time by more than 40%.

A rare change

Bitcoin Core has only adjusted the default dbcache twice before:

Date	Change	Pull Request
2016-07-06	100 → 300 MB	#8273
2017-04-05	300 → 450 MB	#10133
2026-03-06	450 → 1024 MB*	#34692

*Conditional on 64-bit systems with 4+ GB RAM

The 450 MB default has held for nearly nine years, while the blockchain grew from ~100 GB to over 700 GB and the UTXO set expanded from ~2 GB to ~11 GB. Meanwhile, typical consumer hardware evolved: 4 GB of RAM is now entry-level, not high-end.

Simple bump vs. smart scaling

PR #34692 was intentionally simple. It was opened as an alternative to PR #34641, which proposed automatic RAM-based scaling using the formula:

default_dbcache = clamp(100 MB, 0.25 × (system_RAM - 2 GB), 2 GB)

This would have created a sliding scale:

System RAM	Auto-scaled Default
2 GB	100 MB
4 GB	512 MB
8 GB	1536 MB
16 GB+	2048 MB (cap)

The auto-scaling approach would maximize performance for high-RAM systems and minimize memory pressure for low-RAM systems. But it introduced complexity. Developer discussions revealed concerns about:

Surprising behavior: Users might not expect their config to change based on detected RAM
Container edge cases: Containers can misreport RAM (e.g., showing host RAM instead of container limits)
Code complexity: More logic, more edge cases, more potential bugs
Documentation burden: Harder to explain and reason about

PR author andrewtoth framed the simple bump as “a last-minute sneak in to v31,” a conservative change that delivers most of the benefit with minimal risk. Maintainer achow101 agreed and merged it.

The decision reflects a pragmatic philosophy: bump the default for systems that clearly have headroom, but don’t break existing low-resource setups. Users with constrained environments can still set -dbcache manually.

What users should do

If you have 4+ GB of RAM and run Bitcoin Core v31 with default settings, you’ll automatically get faster sync times. No action needed.

If you want to revert to the old behavior, add -dbcache=450 to your bitcoin.conf or command line.

For low-memory systems (under 4 GB RAM), Bitcoin Core will continue using 450 MB by default. If you need even lower memory usage, see reduce-memory.md.

If you’re running containerized nodes, check your container’s memory limit. If it’s tight (2 GB or less), consider setting -dbcache explicitly to avoid out-of-memory issues. The RAM detection logic might see your host’s RAM instead of the container’s limit.

For node distribution platforms like RaspiBlitz, Umbrel, MyNode, or Start9: if your platform already tunes dbcache, Bitcoin Core’s new default may conflict with your custom logic. Review your configuration management.

Looking forward

This change sets a precedent for future adjustments. As Andrew Toth noted in the PR, “the defaults are meant for newbies who aren’t yet configuring, which are likely on higher RAM systems.”

The door is open for further refinements:

More aggressive auto-scaling based on detected RAM (revisiting the approach from PR #34641)
Dynamic dbcache adjustment based on IBD vs. steady-state operation
Profile-based configuration presets (--profile=low-memory, --profile=performance)

Developer ajtowns suggested Bitcoin Core could add startup validation: “if the configuration settings have been left as defaults, check if they’re obviously unreasonable (dbcache is >25% of memory, prune is unset on mainnet and there’s only 20GB of diskspace, etc.) and provide a startup error if so.”

PR #33333 already added warnings for oversized dbcache; tightening this to an error could prevent out-of-memory crashes before they happen.

For now, the simple bump is a win for most users. Faster sync times, lower disk wear, and better validation performance with no configuration required. And if you’re running on a Raspberry Pi with 2 GB of RAM, Bitcoin Core won’t break your setup.