<p>I have done extensive tests without SDD, and later on with SSD. For sure downloading the bitcoin blockchain does not (!) require an SSD. However, everyone knows, it is faster using an SSD. There is heavy disk I/O, storing the blockchain, and there is also heavy CPU usage (re-) calculating the values, before they are stored on the local drive. One can give parameters to the bitcoin core client to increase memory usage (to speed up process), and you can for sure try to play with OS cache. So you need a fair amount of power to get along, and balance the parameters. </p>

<p>The bitcoin blocksize growth is pre-determined, so Moore's law is less relevant, and the blockchain growth is much, much less than Moore's law. Back to SAN: I had an older 1GB/sec attached SAN drive, with redundancy behind, and downloaded the blockchain on a 2 CPU machine. There was no problem, and it took only ~30% of my comparable desktop machine with an INTEL i7 processor (Unix OS). </p>

<p>Reliability of data is given through the SAN architecture, and the query speed is sufficient: you query the blockchain "sequentially", and for sure this is slow. Depends on your use case... But this is independant from the disk subsystem. However, the big "online explorers" (blockchain.info...) re-index the blockchain into the specific addresses, tx IDs and more, so that requests attain a satisfying speed. </p>

CC BY-SA 3.0
2017-12-27T14:19:38.813Z
Is this true though? https://www.reddit.com/r/btc/comments/6vgilz/question_bch_full_node_slow_sync/dm05b08/?st=jbp5az0e&sh=1d0d4fcb
Eddie
CC BY-SA 3.0
2017-12-27T15:28:14.993Z
I cannot judge, from my own experience: there are three areas to look at: network bandwidth (20 mbit should do), the network speed is not so relevant, cause when a block is transferred, the computer starts to decode the block and the tx inside. CPU power and RAM (a RASPI is certainly too slow, but a decent i7 is ok) and a SSD or storage system will bring you to the goal. If you have an older off-the-shelf SAN, with only 2 disks and 100mBit, then you'd go better for an SSD.
pebwindkraft
CC BY-SA 3.0
2017-12-27T16:43:28.923Z
I might try an SSD. Though I question if it will help improve block sync times. For queries, maybe IOPS is important. I synced the testnet in a few days without much trouble. The main network is much slower. CPU, Mem, network, are all good. But I do have a small storage array linked with dual gigebit. I will post if I find something.
Eddie
CC BY-SA 3.0
2017-12-31T03:12:50.570Z
While moving the blockchain to an SSD, I noticed the SAN was using LAN instead of the network bond. That said, the SSD is noticeably faster at syncing blocks. I think there might be something to the IOPS story.
Eddie
CC BY-SA 3.0
2017-12-15T08:36:42.250Z
2017-12-15T08:36:42.250Z
pebwindkraft
<p>I have a few questions. One, is an SSD a good option to store the bitcoin blockchain. To unpack that question more, historically, has the blockchain size kept pace with Moore's law in relation to SSD technology?</p>

<p>Second, is a SAN drive array more appropriate to store bitcoin and other blockchains? I have done this before, it worked for my purpose as bitcoin is rather dynamic and slow compared to a typical database. The storage size is a clear upside. However, I wonder what is the impact with many big queries and also sync times?</p>

<bitcoin-core>
Best practices for storing the bitcoin blockchain?
Eddie
# Best practices for storing the bitcoin blockchain?

(Asked by: username_0 on 2017-12-15)

I have a few questions. One, is an SSD a good option to store the bitcoin blockchain. To unpack that question more, historically, has the blockchain size kept pace with Moore's law in relation to SSD technology?

Second, is a SAN drive array more appropriate to store bitcoin and other blockchains? I have done this before, it worked for my purpose as bitcoin is rather dynamic and slow compared to a typical database. The storage size is a clear upside. However, I wonder what is the impact with many big queries and also sync times?

**Tags:** bitcoin-core


---

## 1 answers

### Answer by username_1 on 2017-12-15. Score: 1 | Accepted answer

I have done extensive tests without SDD, and later on with SSD. For sure downloading the bitcoin blockchain does not (!) require an SSD. However, everyone knows, it is faster using an SSD. There is heavy disk I/O, storing the blockchain, and there is also heavy CPU usage (re-) calculating the values, before they are stored on the local drive. One can give parameters to the bitcoin core client to increase memory usage (to speed up process), and you can for sure try to play with OS cache. So you need a fair amount of power to get along, and balance the parameters.

The bitcoin blocksize growth is pre-determined, so Moore's law is less relevant, and the blockchain growth is much, much less than Moore's law. Back to SAN: I had an older 1GB/sec attached SAN drive, with redundancy behind, and downloaded the blockchain on a 2 CPU machine. There was no problem, and it took only ~30% of my comparable desktop machine with an INTEL i7 processor (Unix OS).

Reliability of data is given through the SAN architecture, and the query speed is sufficient: you query the blockchain "sequentially", and for sure this is slow. Depends on your use case... But this is independant from the disk subsystem. However, the big "online explorers" (blockchain.info...) re-index the blockchain into the specific addresses, tx IDs and more, so that requests attain a satisfying speed.

> **Comments:**
> **username_0**: Is this true though? https://www.reddit.com/r/btc/comments/6vgilz/question_bch_full_node_slow_sync/dm05b08/?st=jbp5az0e&sh=1d0d4fcb  
> **username_1**: I cannot judge, from my own experience: there are three areas to look at: network bandwidth (20 mbit should do), the network speed is not so relevant, cause when a block is transferred, the computer starts to decode the block and the tx inside. CPU power and RAM (a RASPI is certainly too slow, but a decent i7 is ok) and a SSD or storage system will bring you to the goal. If you have an older off-the-shelf SAN, with only 2 disks and 100mBit, then you'd go better for an SSD.  
> **username_0**: I might try an SSD. Though I question if it will help improve block sync times. For queries, maybe IOPS is important. I synced the testnet in a few days without much trouble. The main network is much slower. CPU, Mem, network, are all good. But I do have a small storage array linked with dual gigebit. I will post if I find something.  
> **username_0**: While moving the blockchain to an SSD, I noticed the SAN was using LAN instead of the network bond. That said, the SSD is noticeably faster at syncing blocks. I think there might be something to the IOPS story.  

---

