Storage

Chapter 27: Node Data Storage

Overview

Understanding how blockchain nodes store data is crucial for managing storage requirements and optimizing performance.

27.1 Storage Overview

Ethereum Data Structure

┌─────────────────────────────────────────────────────────────────┐
│                    ETHEREUM STORAGE                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │                    LEVELDB / MDBX                        │  │
│   │                                                          │  │
│   │   Key-Value Store                                       │  │
│   │                                                          │  │
│   │   ┌────────────┬──────────────────┐                    │  │
│   │   │    Key     │      Value       │                    │  │
│   │   ├────────────┼──────────────────┤                    │  │
│   │   │ h:0x0000  │ Block #0        │                    │  │
│   │   │ h:0x0001  │ Block #1        │                    │  │
│   │   │ h:0x0002  │ Block #2        │                    │  │
│   │   │ h:0x...   │ ...             │                    │  │
│   │   │ s:0x...   │ State (accounts)│                    │  │
│   │   │ t:0x...   │ Transactions    │                    │  │
│   │   └────────────┴──────────────────┘                    │  │
│   │                                                          │  │
│   └─────────────────────────────────────────────────────────┘  │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

27.2 Storage Requirements

Ethereum Mainnet

Node Type	Storage Required
Full Node	~1.2 TB
Pruned Node	~1.2 TB
Archive Node	~12 TB

By Component

Data	Approximate Size
Block data	~600 GB
State data	~500 GB
Historical data	~100 GB

27.3 Data Directories

Geth Data Directory

/data/ethereum/
├── geth/
│   ├── chaindata/      # Blockchain data
│   │   └── 000001.log  # LevelDB files
│   ├── triecache/      # Trie cache
│   ├── snapshots/      # State snapshots
│   └── nodes/          # Peer information
├── keystore/           # Account keys
└── history/            # Historical state

27.4 Storage Optimization

Pruning

# Geth prunes state automatically when run with the default --gcmode full
# (only recent state is kept; older state layers are dropped). There is NO
# --pruneancientstore flag — geth moves old blocks/receipts into its ancient
# store automatically and uses --history.* to cap how much it retains:

# Cap retention (blocks): keep last 90k state layers / tx index / receipts
geth --history.state 90000 --history.transactions 90000

# Archive mode — keep the full history (no state pruning):
geth --gcmode archive

# Delete the chain + state databases entirely (real utility):
geth removedb

Snapshots

# Enable snapshots
geth --snapshot=true

Summary

Blockchain nodes store data in key-value databases
Storage requirements vary by node type
Pruning reduces storage needs
Use SSDs for performance

Next Chapter

In Chapter 28: State & Merkle Trie Structures, we’ll explore data structures.

Last Updated: 2026-10-07