Bitcoin Core Doubles Default Cache to 1 GiB: What Node Operators Need to Know | Bitcoin Index

Bitcoin Core is getting faster by default. PR #34692, merged on March 6, 2026, doubles the default database cache from 450 MiB to 1 GiB for systems with at least 4 GB of RAM. The change targets the upcoming v31.0 release and represents the first significant default bump in nine years.

For node operators, this means faster initial sync times, quicker block validation, and reduced disk wear. On some hardware, the improvement is dramatic: benchmarks show sync times cut by up to 75% on high-end systems and 40% on constrained setups like the Raspberry Pi 5.

This is a smart, conservative change that makes Bitcoin Core faster without breaking compatibility for low-memory systems. Here’s what you need to know.

What changed

The dbcache setting controls how much RAM Bitcoin Core dedicates to caching the UTXO (Unspent Transaction Output) set. While the authoritative data lives on disk, the cache acts as a write buffer, reducing the frequency of disk syncs and random write operations.

The new default:

1024 MiB (1 GiB) if your system has 4+ GB of RAM, is running a 64-bit build, and you haven’t manually set -dbcache
450 MiB otherwise (same as before)

If you’re running a Raspberry Pi 4 with 2 GB of RAM or a 32-bit system, nothing changes. If you’re running a modern machine with 8 GB or more, you automatically get the larger cache when v31.0 ships.

This is the first major increase since April 2017, when the default went from 300 MiB to 450 MiB. At the time, contributor Luke Dashjr noted that the UTXO set had grown significantly since the original 100 MiB default was set in 2016. Nearly a decade later, another bump makes sense.

The performance data

The benchmarks are compelling. PR #34641 (an alternative auto-scaling approach) included extensive reindex-chainstate tests across multiple hardware configurations. Here’s what reindexing ~936,000 blocks looked like:

Machine	450 MiB	1000 MiB	Speedup
M4 Max (16c, 64GB, SSD)	5h 37m	3h 12m	1.75x faster
Raspberry Pi 5 (4c, 8GB, SSD)	52h 06m	36h 51m	1.41x faster
i7-7700 (8c, 62GB, HDD)	13h 09m	10h 24m	1.26x faster
i9-9900K (16c, 62GB, SSD)	6h 07m	5h 28m	1.12x faster

The gains range from 10% to 75% depending on hardware. High-end systems see the most dramatic improvement, but even modest setups benefit. Notably, the i7-7700 with a traditional hard drive saw a 26% speedup, which matters because HDDs suffer more from frequent small writes than SSDs.

Why does a larger cache help so much during initial block download (IBD)? Because it reduces the number of times Bitcoin Core has to flush data from memory to disk. Each flush interrupts validation work and creates disk I/O overhead. With a larger cache, you get fewer, larger writes instead of many small ones.

Once your node is synced, the impact is smaller but still measurable: faster block validation during busy periods, reduced disk wear, and better responsiveness during mempool surges.

Who this affects

If you’re running default settings on a system with 4+ GB RAM, you’ll automatically get the 1 GiB cache when v31.0 ships (expected mid-2026). No action required.

If you’re on a low-memory system, nothing changes. The 450 MiB default remains in place for systems with less than 4 GB of RAM. Bitcoin Core will continue working exactly as it does now.

If you manually set -dbcache, your setting takes precedence. Always. The auto-detection only applies when you haven’t explicitly configured cache size.

If you’re running Bitcoin Core in a Docker container with memory limits, this is the one edge case to watch. Bitcoin Core detects RAM using sysconf(_SC_PHYS_PAGES) on Unix systems, which reports the host’s physical RAM, not container limits set via cgroups.

Example problem scenario:

Host has 32 GB RAM
Container is limited to 1 GB via docker run --memory=1g
Bitcoin Core detects 32 GB and sets dbcache to 1024 MiB
Container OOM-kills bitcoind

Solution: If you’re running Bitcoin Core in a container with tight memory limits, explicitly set -dbcache in your bitcoin.conf. Start by checking your startup logs to see what Bitcoin Core detected. VMs (AWS EC2, DigitalOcean, etc.) don’t have this issue because they present the allocated RAM as the system’s total RAM.

Memory footprint: the math

The change increases Bitcoin Core’s default memory usage by roughly 574 MiB on qualifying systems. Here’s the new baseline for v31 with default settings:

Base process overhead: ~300-400 MiB
Mempool (default): 300 MiB
dbcache (new default): 1024 MiB
Total: ~1.6-1.8 GB

This is why the 4 GB threshold exists. It leaves headroom for the operating system and other processes. If you’re running multiple services on a 4 GB machine, you might want to lower the cache manually (-dbcache=300) to avoid memory pressure.

Why not auto-scaling?

There was a more aggressive alternative on the table. PR #34641 proposed a formula that would scale cache size based on available RAM:

default_dbcache = clamp(100 MiB, 0.25 * (total_RAM - 2 GiB), 2 GiB)

Under this approach:

4 GB systems: 512 MiB
8 GB systems: 1536 MiB
16 GB+ systems: 2048 MiB (capped)

Why was it rejected for v31? Too complex, too close to the release cutoff. From the February 2026 Core dev meeting:

“If we want to get that in for 31, we want to try and stem the scope creep there. Trying to do stuff like detecting containerisation, is too much, for what could be a one-liner change plus release notes.”

Contributors preferred a simple, well-tested change over a more sophisticated system that might behave unpredictably across diverse environments. Contributor kevkevinpal summarized it well:

“This looks good to me, I think it makes sense to continue to support low RAM systems and not do a simple bump. This is good to get into the v31.0 release without being too complicated and revisit the autoscaling RAM in a later release if desired.”

The auto-scaling idea isn’t dead. It may return in a future release once the simpler change has been field-tested.

Should you adjust manually?

For most operators: no. The automatic behavior is sensible and well-tuned.

When to manually set -dbcache:

You’re memory-constrained: Running multiple services on a 4 GB system? Set -dbcache=300 or lower to free up RAM for other processes.
You want faster IBD: If you have 16+ GB of RAM and want to speed up initial sync, set -dbcache=4096 (or higher) during IBD, then lower it afterward. The benchmarks show diminishing returns beyond 2 GB, but if you’re willing to dedicate the RAM, it still helps.
You’re in a container: Always set -dbcache explicitly if you’re running with memory limits. Check your startup logs to verify what Bitcoin Core detected.
You’re on an older release: This change only affects v31+. If you want the performance benefit now, add -dbcache=1024 to your bitcoin.conf manually.

When does this ship?

PR #34692 was merged on March 6, 2026, and tagged for the v31.0 milestone. Based on Bitcoin Core’s typical six-month release cycle, v31.0 is expected around mid-2026. No official date has been announced yet.

Final thoughts

This is the kind of unsexy, practical improvement that makes Bitcoin Core better without fanfare. Faster syncs, less disk wear, better performance on modest hardware. The 4 GB threshold is smart: it targets the vast majority of modern systems while preserving compatibility for resource-constrained setups.

The only real gotcha is containerized deployments, and even that’s easily mitigated with explicit configuration. For everyone else, this is a free lunch.

Good work by andrewtoth and the reviewers who pushed this through. Sometimes the best changes are the simple ones.

Sources

Sources: Bitcoin Core PR #34692, Bitcoin Core PR #34641, Bitcoin Core PR #10133, Bitcoin Stack Exchange: What is dbcache?, Bitcoin Stack Exchange: UTXO cache behavior. Data/PR status as of March 2026.