How fast is Ethereum blockchain growing and how big is it likely to get in the future? Is it still about 1 GB per month? Are there any data pruning or compression algorithms in place?


Update on Dec 9th, 2018 / Block ~ 6_850_000 - It's quite an annoyance to keep this answer updated. Therefore, I created two tracking sites for full and archive nodes:

Geth (Go)

Last Update: May 14th, 2018 / Block ~ 5_600_000

Client / Mode         | Block Number   | Disk Space
geth light            | 5_600_000      | 363M
geth fast full        | 5_600_000      | 142G
geth full full        | ?_???_??? [1]  | 239G + [1]
geth full archive     | 4_980_000 [2]  | 671G
  • [1] My disk was full, I didn't expect this to run out of space and wasn't able to repeat this sync mode
  • [2] I didn't manage to sync the archive node within six weeks, unfortunately fully.
  • Geth 1.8.3
  • Ubuntu 16.4 LTS, VPS instance with SSD backed storage

Parity (Rust)

Last Update: May 14th, 2018 / Block ~ 5_600_000

Client / Mode         | Block Number   | Disk Space
parity light          | 5_600_000      |  89M
parity warp fast      | 5_600_000      |  82G
parity full fast      | 5_600_000      |  78G
parity full archive   | 5_600_000      | 1.1T
  • Parity 1.10.0
  • Ubuntu 16.4 LTS, VPS instance with SSD backed storage

Update: Nov 29th, 2017. I have written a blog post about this, esp. parity pruning modes: The Ethereum-blockchain size will not exceed 1TB anytime soon.

Some Sheet.

  • 2
    If ethereum gets used as much as bitcoin is today (around 5tx/sec), that 28x the growth rate. Assuming people use more smart contracts and don't just speculate like they do with Bitcoin, you will see lots of smaller transactions. There will be some consolidation as more transactions are mined in a block (which uses a bit fewer bytes per transaction), but overall, I would expect 600gb-1TB per year of block chain growth if Ethereum gets popular. – Erik Aronesty Feb 2 '16 at 18:04
  • 1
    @5chdn Assuming these figures are still correct, if I were to set up a new wallet and did my first sync using geth -fast, the bandwidth I would use for that first sync would be around 4.348GB ??? Is that right? – TryHarder Nov 22 '16 at 23:14
  • 2
    Yes. Should be a little bit more by now. – Afri Nov 23 '16 at 11:31
  • 3
    Post your ETH address, I'll send you a donation. – nchinda2 Jul 9 '17 at 18:24
  • @nchinda2 0x006ed403807ae87b9f958f25c33862927ba1b57b :) – Afri Sep 18 '17 at 13:22

Currently, the network is growing at around 1GB per month. It's hard to anticipate how large it could grow and at what pace, but there are already efforts underway to implement state-tree pruning in various clients. These techniques will contribute towards so-called "light-clients".

In linked chart above, Block size evolution estimating block size in bytes over time that can be used to estimate velocity (rate). The most appropriate graph depends on what you mean specifically by block growth rate.

  • 2
    which one (or combination?) of the charts linked above shows the block growth rate? None of the individual charts seems to show this directly. – zanzu Feb 18 '16 at 17:03
  • "Block size evolution" will be an estimate of block size in bytes over time that can be used to estimate velocity (rate). The most appropriate graph depends on what you mean specifically by "block growth rate" – Taylor Gerring Feb 18 '16 at 17:09
  • 1
    I tried to find a definition of what etherchain.org means by "block size evolution", but I failed to find any. My interpretation (possibly wrong) is that this represents size of individual blocks averaged on a daily basis. To translate this to an estimate of the blockchain size growth rate over a month (which is what I meant to write in my previous message), we'd need to multiply this by the number of blocks added in a month. – zanzu Feb 18 '16 at 17:18

As of today, ethereum blockchain (ETH, i.e. supporting DAO fork) downloaded in full mode occupies 75GB on my drive. Client is geth (go-ethereum), version 1.4.18, built from source cloned from https://github.com/ethereum/go-ethereum, running on CentOS Linux release 7.2.1511.

  • As of today should be, as of mm/dd/yyyy for each and every answer... – eugene_sunic May 3 '18 at 20:39

I've stumbled upon the links bellow :

1- provides an online chart which presents the Ethereum's blockchain current size evolution alongside the Bitcoin blockchain's size.

http://bc.daniel.net.nz/ enter image description here

2- provides details about the Ethereum network including the blockchain size https://bitinfocharts.com/ethereum/


Benchmarks done on Homestead in june 2016

Geth 1.4.9 on i7 3720QM 16GB ram and SSD

|      -    |  Full  |  Fast  |  Light  |
| Disk      |  22GB  | 4.8GB  |  600 Mo |
| Time      |  5h    | 21m    |  21m    |

Parity 1.2 on i7 3720QM 16GB ram and SSD

| -         | Archive  |  Fast  |  Light  |
| Disk      |  22GB    | 3.7GB  |  2.5GB  |
| Time      |  2h      | 1h30   |  2h     |
  • 1
    I wonder why my results disk space needs from one month ago are higher than yours now... – Afri Jul 1 '16 at 9:04
  • i will update them in few hours – Ellis Jul 1 '16 at 9:07

As of February 1, the blockchain size is ~940k blocks, with a new block being created every 17.2 seconds. This means, on average, the blockchain increases by 152,790 blocks every month.

A rough average block size, at this time, is around 1,225 bytes. With this average block size, the blockchain size increase is 187MB per month (152,790 blocks x 1,225 bytes).

Reference used: https://www.etherscan.io


I'm syncing a node in full mode. At the moment it' on block 5005306 (end of January 2018) and it is 700Gb. It's probably been running for more than 20 days

  • Did you use geth or parity. If geth did you use --gcmode=archive option? – medvedev1088 Mar 4 '18 at 18:02
  • geth with the syncmode=full option. I did not use the gcmode option. I dindt even know what it was before your commet. It seems something new on geth 1.8? Im using 1.7 – Diego Mar 4 '18 at 20:20
  • Yes in Geth 1.8 there is automatic pruning enabled by default. gcmode=archive disables it. – medvedev1088 Mar 4 '18 at 20:35
  • am I correct in assuming that's new to 1.8? because on 1.7 sync mode full is enough to avoid prunning – Diego Mar 4 '18 at 22:00
  • Yes that’s correct. – medvedev1088 Mar 4 '18 at 22:38

protected by Afri Dec 30 '16 at 8:31

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.