Minimum Disk Space for Running a Bitcoin Node

Hey everyone, I’m trying to build an app for bitcoin enthusiasts, but I need to get some info from a Bitcoin node via RPC calls. My focus is solely on the mempool, nothing else. I’ve been tinkering with configurations and found that even when I prune heavily, the.bitcoin folder still takes up around 12 GB due to the chainstate being 11 GB. Is there a way to shrink that further? I’m running on a cloud setup with only 25 GB total and 12 GB is just too much.

I don’t think that’s doable. Chainstate is essential for Bitcoin Core to identify which transactions are valid in your mempool.

You might want to check the maxuploadtarget setting, could help with your needs.

Nah, bandwidth doesn’t affect disk usage at all.

Thanks for the input. If you’re right, it looks like I’ll have to either rent another drive or find a public Bitcoin node that allows external RPC calls. I only need one call every five minutes, which adds up to 288 a day.

That’s impossible. Chainstate, which has the UTXO data, is critical to ensure transactions abide by Bitcoin protocol rules.

There are a few third-party services that let you do RPC calls supported by full nodes. I’ve heard of getblock.io offering that, but never actually used it, so do your own research.

Most blockchain explorers have public APIs, but you’d need to trust their accuracy. If that fits your needs, you could look into BlockCypher or SoChain. Just a heads up, without running your own node, you can't verify the data.

I think if you crank up the dbcache enough, it might keep the chainstate in RAM, only flushing it to disk on exit. Not super practical though. You could try deleting the folder when done, but not sure how Bitcoin Core would react.

Getblock is legit; I’ve used it before.

But OP would need a VPS with at least 12 GB. My Bitcoin Core chainstate is around 10.8 GB, and you also need about 300 MB of RAM for mempool and some more for the OS.

Yeah, good point. Just remember you can add more RAM each year as needed.

Storage is cheaper than RAM, and if your chainstate is in RAM, any RAM corruption could cause serious issues, leading to needing another reindex. It’s likely Bitcoin Core still reserves some disk space for chainstate.

True, but if you're low on RAM, more storage isn’t gonna fix that.

RAM failures can mess up your whole setup. Luckily, once installed properly, it doesn’t fail often. Each time Bitcoin Core verifies a block, it’s reading/writing to chainstate a lot, so low RAM could slow things down.

Exactly, that’s why serious setups use ECC RAM. Even small errors in chainstate can be problematic.

Bitcoin Core only uses as much chainstate in RAM as you let it. Keeping the whole thing in RAM all the time could create more issues than it solves.

I haven’t tested it, but comparing disk writes during IBD on low RAM vs a system with 32 GB dbcache would be interesting. Just don’t have the RAM to try it out.

I once synced a pruned node in /dev/shm. It worked fine.

Including swap, I guess? If you want the chainstate in RAM, then flushing is expected. Using /dev/shm as a ramdisk means you’ll only get half the RAM, and you’ll need to consider overheads. Probably better to just add more storage than to push your RAM.