Node Storage Growth Calculator
Solve the blockchain data growth identity Growth = Block Size × Blocks/Day × Days for any of its four variables — the total storage growth, the average block size, the blocks per day, or the time horizon — with step-by-step math, a live storage-growth schematic, a pruning and retention analysis, a hardware-capacity planner, a sync-time estimator, and an archive-vs-pruned comparison.
Blocks per day = 86,400 ÷ block time in seconds. Bitcoin's 10-minute target yields 144 blocks/day; Ethereum's 12-second slots yield 7,200; Solana's 400 ms slots yield 216,000. The blocks-per-hour figure is useful for estimating growth at short horizons, and the blocks-per-year is what you multiply by average block size to get annual growth. Click Apply to load the derived figure into the blocks-per-day field.
Pruning discards old state that the node no longer needs to validate new blocks — Bitcoin's pruned mode keeps the last few GB of blocks, Ethereum's post-merge node keeps only the last 128 blocks of state, and Solana supports an accounts-db-only mode. A pruned node reaches a steady state where the on-disk size is roughly retention days × daily growth, plus a fixed overhead for the node software and indexes. Enter a retention window to compare pruned versus archive sizes: a node with 30-day pruning on a chain growing 1 GB/day sits at ~30 GB of chain data, while the same node in archive mode grows unbounded. This is the single largest driver of hardware cost for node operators.
Node operators should target at least 50% free space on their chain-data disk at all times. The recommended disk figure is the amount required to hold the projected growth over the same period with a 1.5× safety margin — enough to accommodate faster-than-expected growth, snapshot files, and the temporary space needed for database maintenance and compaction. Running a node at 90% disk utilisation is a common cause of sync failures, corruption, and downtime; always size up rather than sizing exactly. For archive nodes with no pruning, the correct answer is often "there is no disk large enough" — the chain grows unbounded, so archive nodes need to plan for periodic storage additions.
A full sync downloads the entire chain from peers, so the minimum sync time is chain size ÷ bandwidth. Real syncs are slower because peers are not always available at full speed, the node must also validate every block (CPU-bound), write to disk, and process state. A reasonable rule of thumb is that a real sync takes 2–4× the raw download time on a fast connection, and much longer on a slow one. The effective column applies a 60% efficiency factor — closer to what most operators observe on a residential or small-VPS connection. Archive-node syncs are always significantly longer than pruned-node syncs because they must download the full historical chain.
Two identical nodes running the same chain can require wildly different storage. An archive node keeps every block and every state transition since genesis, growing without bound. A pruned node discards historical state beyond the retention window, reaching a steady-state size that is roughly the daily growth multiplied by the retention period, plus a fixed overhead. On Ethereum, an archive node is well over 15 TB; a pruned execution node with default settings is 1.2–1.5 TB. On Bitcoin, an archive node is roughly 700 GB; a pruned node can be under 10 GB. The trade-off is query capability: archive nodes can answer questions about historical state, while pruned nodes cannot. For most operators, pruned is the right default — archive is only necessary for block explorers, analytics providers, and RPC services that need full historical state.
Storage growth is linear in every variable — which makes planning tractable
Block size, blocks per day, and the time horizon all enter the formula multiplicatively, so the total growth scales proportionally with any of them. Doubling the block size doubles the storage requirement; halving the block time doubles the number of blocks per day and therefore doubles the growth; doubling the planning horizon doubles the eventual disk requirement. This linearity makes storage planning one of the few areas of node operations where the arithmetic is genuinely predictable. The catch is that all three inputs are estimates: block sizes vary, block times drift, and the horizon is a guess. Sensible operators plan against the upper end of the plausible range for each input, not the average.
Pruning turns unbounded growth into bounded cost
Without pruning, every node is an archive node and disk requirements grow without bound — Ethereum's full archive is well over 15 TB in 2024 and rising, Bitcoin's is around 700 GB. Pruning discards historical state that the node no longer needs to validate new blocks, which reduces the on-disk footprint to roughly the retention window multiplied by the daily growth, plus a fixed overhead. A pruned Bitcoin node can run under 10 GB; a pruned Ethereum execution node sits around 1.2 TB. The trade-off is that pruned nodes cannot answer historical state queries — they cannot be used as block explorers or analytics backends. For most operators the calculation is clear: prune unless you specifically need the history.
Node disk is not just chain data
The chain data growth figure from this formula is the largest component of node storage, but it is not the only one. A production node also carries the operating system (5–20 GB), the node software and its dependencies (often several GB), the database overhead and indexes (typically 20–40% on top of raw chain data), the mempool or transaction pool (variable, occasionally a few GB), and any monitoring or logging tooling. When planning hardware, a common mistake is to size the disk exactly to the projected chain size. The correct approach is to add 30–50% for these additional components, plus a further 50% margin for safety. The capacity planner in this calculator does both.
Chain growth accelerates over long horizons
Projecting storage growth linearly over ten years assumes the average block size and block rate stay constant, which is rarely true. Chains that gain adoption produce larger blocks, chains that introduce new opcodes or precompiles increase state bloat, and gas limits that are periodically raised directly increase the block size. Ethereum's block gas limit has risen from 10 million at launch to 30 million today; Bitcoin's block weight is repeatedly close to the 4 MWU cap. A safe assumption for a ten-year projection is that the actual growth will be 1.5–3× the linear projection. Plan for a disk you can expand, not one you size exactly to a linear forecast.
How to Use This Calculator
The storage growth relation links four quantities: the total growth, the block size, the blocks per day, and the number of days. Pick which one you want the tool to solve, then fill in the other three.
1. Choose what to solve for
Pick Growth, Block Size, Blocks/Day, or Days from the toggle. The calculator rearranges Growth = Block Size × Blocks/Day × Days automatically for whichever variable you choose and greys out that field.
2. Get an honest block size
Block sizes vary continuously. For Bitcoin use the average over the last 30 days — around 1.5 MB in 2024, not the 4 MB maximum. For Ethereum use the average execution block size. For fixed-block-time chains with variable sizes, sample a representative week and average it.
3. Derive blocks per day from block time
Use the block-time helper. Enter the chain's target block time in seconds and the calculator computes blocks/day = 86,400 ÷ block time. Bitcoin is 600 seconds, Ethereum is 12 seconds, Solana is 0.4 seconds. Click Apply to load the result.
4. Read the growth band and chips
The result card places the growth on a log-scale band from 1 GB through 100 TB, with a colour-coded verdict from tiny through huge. The chips show the daily growth rate, the annual growth, and the archive-vs-pruned factor.
5. Check pruning and capacity
Set a retention window in the pruning helper to see how much disk pruned mode saves. Use the capacity planner to enter your available disk size and find out how many days until it fills — and what size disk you would need with adequate headroom.
6. Switch to Advanced for depth
Advanced mode adds a growth-vs-block-size chart, a sensitivity check on ±1% input changes, and companion metrics including daily and hourly growth, the disk fill date, the recommended disk with headroom, and the sync-time estimate for a full node.
What This Tool Offers
Built around the blockchain storage identity Growth = Block Size × Blocks/Day × Days, the calculation every node operator runs before buying hardware.
Four-way solving
Solve for the total growth, the block size, the blocks per day, or the number of days. Useful for working backwards from a disk budget to the maximum horizon it supports, or from an observed growth rate to the average block size.
Block time converter
Enter the chain's block time in seconds to derive blocks per day, per hour, and per year, with one click to load the result into the calculator. Covers Bitcoin, Ethereum, Solana, and any custom block time.
Pruning analysis
Enter a retention window to compare archive size vs. pruned size at steady state, and see the space saved as a percentage. Captures the single largest driver of node hardware cost.
Hardware capacity planner
Enter available disk and OS overhead to see usable space, days and years until the disk fills, and the recommended disk size with a 1.5× headroom margin — the practical answer to "what disk should I buy?".
Sync-time estimator
Enter download bandwidth to estimate the raw download time and the more realistic effective sync time, which accounts for peer variance, validation overhead, and disk I/O.
Reference tables
A live growth converter with unit conversions, a growth lookup grid across block sizes and horizons, typical chain parameters by network, and a full variable reference.
Reference Tables & Conversions
A live growth converter with unit conversions, a growth lookup grid, and typical chain parameters by network.
Block size · blocks/day · days · growth converter
Growth Lookup — Block Size × Horizon at 7,200 Blocks/Day (Ethereum Pace)
Each cell shows the total storage growth for a given average block size and time horizon, assuming Ethereum's block rate.
| Block size | 1 day | 30 days | 90 days | 1 year | 5 years | 10 years |
|---|
Typical Chain Parameters & Storage Growth
Representative figures for major chains as of 2024. Actual growth depends on network activity, average transaction size, and the node's mode (archive vs pruned).
| Chain | Block time | Avg. block size | Blocks/day | Daily growth | Annual growth | Archive size (2024) |
|---|---|---|---|---|---|---|
| Bitcoin | ~10 min | ~1.5 MB | 144 | ~216 MB | ~79 GB | ~700 GB |
| Ethereum (execution) | 12 s | ~100–150 KB | 7,200 | ~0.9 GB | ~330 GB | ~15 TB (full archive) |
| Ethereum (consensus) | 12 s | ~50–100 KB | 7,200 | ~0.5 GB | ~180 GB | ~1.2 TB |
| Solana | ~400 ms | variable (avg ~500 KB–1 MB) | up to 216,000 | ~50–200 GB | unrealistic — very high | ~100 TB+ (full), ~200 GB (accounts-db only) |
| Litecoin | 2.5 min | ~50–100 KB | 576 | ~50 MB | ~18 GB | ~60 GB |
| Dogecoin | 1 min | ~10–100 KB | 1,440 | ~50 MB | ~18 GB | ~70 GB |
| BSC | 3 s | ~100–500 KB | 28,800 | ~5 GB | ~1.8 TB | ~3.5 TB (full), ~1.5 TB (pruned) |
| Polygon PoS | 2 s | ~50–200 KB | 43,200 | ~5 GB | ~1.8 TB | ~2 TB+ (full) |
| Avalanche C-Chain | 2 s | ~50–200 KB | 43,200 | ~3 GB | ~1.1 TB | ~500 GB – 1 TB |
| Cosmos Hub | 6 s | ~50–500 KB | 14,400 | ~2 GB | ~730 GB | ~200–400 GB |
| Cardano | 20 s | ~10–80 KB | 4,320 | ~200 MB | ~73 GB | ~150 GB (full) |
| Arbitrum One | ~250 ms (L2 blocks) | variable (batched to L1) | ~345,600 | ~variable | ~100–300 GB (node) | ~2 TB (full archive) |
Variable Reference
| Symbol | Meaning | Typical range | Units |
|---|---|---|---|
| G | Total storage growth | 10⁶ – 10¹⁵ | bytes |
| B | Average block size | 10³ – 10⁸ | bytes |
| n | Blocks per day | 100 – 10⁶ | blocks/day |
| t | Time horizon | 1 – 10,000 | days |
| Tb | Block time | 0.1 – 600 | seconds |
| R | Pruning retention | 0 – 10,000 | days |
| D | Available disk | 10⁹ – 10¹⁴ | bytes |
| BW | Download bandwidth | 1 – 10,000 | Mbps |
What Does Growth = Block Size × Blocks/Day × Days Measure?
This relation measures how much data a blockchain node will write to disk over a given period, assuming it processes every block the network produces. It is the product of three quantities: the average size of each block, the number of blocks the chain produces in 24 hours, and the number of days you are planning over. The result is the raw chain growth before pruning, and it is the single number that determines whether a node can run on a consumer SSD or needs enterprise storage.
Node Storage Growth Formula
The defining relationship is:
Rearranged to solve for the other three unknowns:
Blocks/Day = Growth ÷ ( Block Size × Days )
Days = Growth ÷ ( Block Size × Blocks/Day )
Blocks per day follows directly from the block time, which is often the easiest parameter to look up:
Daily growth — the number that determines how quickly a disk fills — is the same formula with Days = 1:
The pruned-node steady-state size, which is what the disk actually needs to hold in a pruned configuration, is:
And the days until a disk fills, given the usable capacity for chain data, is:
Node Storage Variables
| Symbol | Meaning | Notes |
|---|---|---|
| G | Total storage growth | Raw chain growth, before pruning |
| B | Average block size | Use a 30-day average, not the maximum |
| n | Blocks per day | Set by block time: 86,400 ÷ block time |
| t | Days | 365 for annual figures; multiply for years |
| Tb | Block time | Bitcoin 600s, Ethereum 12s, Solana 0.4s |
| R | Pruning retention | 0 for archive, 30–90 days typical for pruned |
| D | Available disk | Subtract OS and node overhead before dividing |
How Each Variable Affects Storage Growth
Growth is linear in all three variables, which means the marginal effect of each is independent of the others. Increasing block size by 10% increases growth by 10% at any horizon. Increasing blocks per day by 10% — which happens whenever the block time shortens by 10% — does the same. And extending the horizon by 10% increases growth by 10%. This linearity makes the arithmetic easy, but it also means that errors compound: an estimate that is 20% high on block size and 20% high on blocks per day over-estimates growth by 44%.
The block size is the variable with the most uncertainty, because it varies continuously with network activity. Bitcoin blocks are almost always near the maximum weight because the network is congested; Ethereum blocks vary from empty to full depending on gas demand; Solana produces blocks at a rate that is independent of the actual transaction volume, and individual block sizes vary by several orders of magnitude. Using a single average figure is a simplification that works for long-horizon planning but not for short-horizon capacity planning on high-variance chains.
The blocks-per-day figure is the most predictable of the three, because it is set by the block time and the block time is a protocol constant for most chains. Bitcoin's ten-minute target means 144 blocks per day, on average — occasionally the network produces slightly more or fewer due to difficulty adjustments, but the long-run average is very stable. Ethereum's twelve-second slots yield exactly 7,200 slots per day, though not every slot contains an execution block. Solana's 400-millisecond target yields 216,000 blocks per day in theory; in practice the network has occasionally halted, so the effective figure is somewhat lower.
The time horizon is the variable most often underestimated in node planning. A node operator who checks that their disk can hold one year of growth will often find themselves running out of space in the second year, particularly if the chain is growing faster than expected. The right practice is to plan for the longest horizon you expect to run the node, plus a 50% safety margin, and to select hardware that allows for storage expansion — a chassis with free drive bays, or a host with a separate data volume that can be resized independently. Chain growth is one of the few things in computing that is genuinely irreversible: once the data exists, the node needs to hold it or prune it, and there is no way to make it smaller retroactively.
Node Storage Calculation Examples
Growth = 1,500,000 × 7,200 × 365 = 3.94 × 10¹² bytes
≈ 3.94 TB ≈ 3.59 TiB
Growth = 1,500,000 × 144 × 365 = 78.84 GB
≈ 73.42 GiB
Block Size = 100 × 10⁹ ÷ ( 7,200 × 365 ) = 38,052 bytes
≈ 38 KB per block
Blocks/Day = 100 × 10⁹ ÷ ( 1,500,000 × 365 ) = 182.6 blocks/day
≈ a 473-second block time
Days = 100 × 10⁹ ÷ ( 1,500,000 × 7,200 ) = 9.26 days
At Ethereum's block rate, 1.5 MB blocks fill 100 GB in under ten days
Daily = 1,500,000 × 7,200 = 10.8 GB/day
Hourly = 10.8 GB ÷ 24 = 450 MB/hour
Monthly = 10.8 GB × 30 = 324 GB/month
Usable = 2,000 − 20 = 1,980 GB
Days until full = 1,980 ÷ 10.8 = 183.3 days ≈ 6 months
At Ethereum's growth rate a 2 TB disk lasts about half a year
Pruned chain data = 10.8 × 30 = 324 GB
Plus overhead ≈ 100 GB → total node ≈ 424 GB
Archive vs pruned saving over 5 years: (5×365 × 10.8 − 324) ÷ (5×365 × 10.8) = 95%
Frequently Asked Questions
It depends entirely on the chain and the node mode. For a pruned Bitcoin node with default retention, 10–20 GB of chain data plus 10–20 GB of overhead is enough, so a 100 GB SSD is comfortable. For an archive Bitcoin node, you need the full 700 GB and rising, so a 1 TB SSD with headroom. For Ethereum, a pruned execution node needs 1.2–1.5 TB, and an archive node needs 15 TB or more. For Solana, the accounts-db-only mode runs on 200–500 GB, but a full validator wants 2 TB of fast NVMe plus a separate accounts-db drive. The key is to check the chain's specific requirements and always size up rather than sizing to the projected minimum. Running a node above 90% disk utilisation is a common cause of sync failures and corruption.
An archive node keeps every block and every state transition since genesis, growing without bound as the chain grows. It can answer historical queries — "what was this account balance at block 5,000,000?" — which makes it necessary for block explorers, analytics providers, and RPC services that need full history. A pruned node discards historical state beyond a retention window, keeping only what it needs to validate new blocks. This reduces storage dramatically — often by 90% or more — but the node cannot answer historical state queries. For most operators running a node to support the network or to validate their own transactions, pruned is the correct default. Archive mode is only necessary when the node is used as a data source for applications that need history.
Yes, on most mature chains, and it is one of the reasons linear projections are optimistic. Storage growth is the product of block size and blocks per day, and both of these tend to increase as the chain gains adoption. Ethereum's block gas limit has risen from 10 million at launch to 30 million today, so average block sizes have roughly tripled. Bitcoin's block weight is repeatedly pressed against the 4 MWU cap, so blocks are effectively at maximum size already. Chains that reduce block times — Solana targets 400 ms, and several L2s settle every few seconds — multiply the daily growth by the inverse of the block time. A projection that assumes constant block size and block time over five years will under-estimate growth by 1.5–3× in most cases.
The raw chain data is the largest single component, but a functioning node carries several other things that add up. First, the operating system itself takes 5–20 GB depending on the distribution. Second, the node software and its dependencies — database libraries, monitoring tools, log rotation — typically take several GB. Third, the database overhead on top of raw chain data is typically 20–40%: indexes, metadata, write-ahead logs, and internal fragmentation. Fourth, the mempool or transaction pool holds pending transactions, occasionally reaching a few GB during network congestion. Fifth, any tooling the operator runs — Prometheus, Grafana, log aggregation — adds overhead. And sixth, database maintenance operations (compaction, snapshot creation) temporarily require free space equal to a significant fraction of the database. A safe rule is to size the disk at 2× the projected chain growth.
NVMe SSD is the standard for anything that needs to keep up with the chain's block production in real time. A spinning disk works for an archive node that syncs slowly and is not expected to answer queries quickly, but it will fail to keep up with high-throughput chains during catch-up. For a validator or a node that needs to be online at every block, NVMe is mandatory — both for write throughput and for random-read performance when the node has to look up state. For archival storage where the node is not expected to stay in sync, HDD is fine and much cheaper per terabyte. The recommended pattern for production nodes is a small NVMe boot drive plus a larger NVMe data drive for the chain, with periodic snapshots copied to cheaper storage for backup.
Not the chain growth itself — it is set by the network's consensus rules and the block production rate, neither of which an individual operator can change. What you can change is how much of that growth lands on your disk. Pruning is the largest lever: setting a short retention window reduces the on-disk footprint from unbounded to a bounded steady state. Running a light client or a snapshot-based node instead of a full validator reduces storage further but limits what you can do with the node. On Ethereum, running a consensus client with checkpoint sync skips most historical state, and running an execution client in snap-sync mode skips the pre-merge chain. On chains that support it, state expiry or stateless clients promise further reductions in future upgrades. For most operators the answer is simple: run a pruned node and keep an archive elsewhere if you need it.
The theoretical minimum is chain size divided by download bandwidth, but the real time is typically 2–4 times longer. The node is not only downloading — it is also validating every block (CPU work), verifying state transitions (CPU and memory), and writing to disk (I/O). On a fast connection with modern hardware, a pruned Ethereum node syncs in 6–12 hours with checkpoint sync, and an archive Ethereum node syncs in several days. Bitcoin's pruned node syncs in 4–8 hours on modern hardware; the archive node takes 1–3 days. A Solana validator can take a week or more to fully catch up. The bandwidth calculator in this tool gives the raw download time; multiply by 2–4 for a realistic estimate, and remember that the disk must be fast enough not to be the bottleneck during the high-write-rate phase of the sync.
Variables
| Symbol | Quantity | Unit |
|---|---|---|
| Storage Growth | Additional storage required | GB |
| Average Block Size | Average size per block | MB |
| Blocks per Day | Blocks produced per day | |
| Days | Number of days | days |
What it means
Running a full blockchain node requires storing the entire blockchain. The storage growth is the rate at which the blockchain size increases. This is used to plan storage capacity and to assess the decentralisation of a network (larger storage requirements can reduce node count). Understanding this helps node operators and developers design efficient storage solutions. It is a key consideration in blockchain scalability discussions.
Worked example
Node Storage Growth – Two Detailed Examples
Real‑World| Parameter | Value |
|---|---|
| Avg Block Size (MB) | 1.5 |
| Blocks/Day | 144 |
| Days | 365 |
| Parameter | Value |
|---|---|
| Avg Block Size | 0.09 MB |
| Blocks/Day | 6500 |
| Days | 365 |
Common mistakes
- Average block size: The average size of blocks (e.g., in MB).
- Blocks per day: The number of blocks generated daily.
- Days: The number of days over which growth is estimated.
- Storage growth: Additional storage required for the node.
- Pruning: Full nodes can prune old data to reduce storage.
Applications
Blockchain node storage growth estimates the increase in storage requirements over time, based on average block size and block rate. This is important for node operators to plan for hardware capacity and costs. By projecting growth, they can ensure their nodes remain operational and avoid storage shortages. This metric also influences the decentralisation of the network, as high storage requirements may limit participation. Understanding storage growth is crucial for maintaining blockchain infrastructure.
- Planning storage capacity for blockchain nodes
- Assessing the feasibility of running a full node
- Budgeting for hardware upgrades
- Evaluating the impact of block size increases
- Educational understanding of blockchain scalability
Related calculators · Mining & Blockchain
Recently updated formulas
Suggest an improvement
Found a mistake? Have a better example? Let us know.
You may send up to 3 suggestions per 24 hours.