Full vs. Pruned Nano Node Storage: When to Keep or Drop the Ledger

Problem Statement

Running a Nano node can be done in two distinct storage modes: full, which keeps the entire block‑lattice, or pruned, which drops older blocks after a configurable window. The decision hinges on how much disk you can spare, how quickly you need to sync, and whether you require independent verification of historic transactions.

Decision & Constraints

Choose full node storage if:

• you need to validate any transaction from the genesis block to the present without external help,
• you want to serve the full ledger to other peers or clients, or
• you can afford the current ledger size (~5 GB as of 2026).

Opt for pruned node storage when:

• disk space is limited (e.g., <200 MB for a 1000‑block window),
• fast initial sync is a priority, or
• you are willing to rely on other nodes for historical data beyond the pruning window.

Compact Trade‑off Table

Trade‑off Explanation

Full nodes provide the highest level of decentralization: every transaction can be re‑verified locally. This is essential for nodes that offer services like block explorers or audit tools. However, the storage cost grows linearly with time, and the initial sync can take hours on modest hardware.

Pruned nodes trade off the ability to prove old transactions for reduced disk consumption and faster sync. They are suitable for lightweight setups, embedded devices, or users who only care about current balances. The pruning window is usually set in blocks; a common default is 1000 blocks, which covers roughly the last 2–3 hours of activity.

Concrete Implementation: Enabling Pruning

Prerequisites

• Operating system: Linux or macOS (Windows support via WSL)
• Nano node 2026.x (check with nano-node --version)
• Root or sudo privileges for file system changes

Configuration Steps

1. Open the node’s configuration file (default: /etc/nano-node/config.json or ~/.nano-node/config.json).
2. Add or modify the following entries:

   {
     "enable_pruning": true,
     "pruning_limit": 1000
   }

3. Save the file and exit the editor.
4. Restart the node:

   sudo systemctl restart nano-node

After restart, the node’s log should contain lines similar to:

2026-10-10 15:30:01 INFO Pruning enabled
2026-10-10 15:30:01 INFO Pruning limit set to 1000 blocks

Validation Checks

Confirm pruning status via RPC:

curl -s -X POST -H "Content-Type: application/json" \
  -d '{"action": "ledger_info"}' \
  http://127.0.0.1:7075 | jq '.pruning_enabled, .block_count'

Expected output:

true
1000

Next, verify disk usage:

df -h /var/lib/nano-node/ledger

The reported size should be in the hundreds of megabytes for a 1000‑block window, compared to ~5 GB for a full node.

Pruning Limit Adjustments

If you later decide to increase the pruning window, you must resync the node. Changing pruning_limit on a running node does not retroactively fetch or delete data. To modify the limit safely:

1. Stop the node: sudo systemctl stop nano-node
2. Delete the existing ledger directory: sudo rm -rf /var/lib/nano-node/ledger
3. Update pruning_limit in config.json.
4. Restart the node and allow it to sync from scratch.

Note: This downtime is unavoidable because the ledger must be rebuilt to satisfy the new retention policy.

Practical Check for Historical Data Needs

To determine if pruning will affect your use case, run a quick query against a known historic transaction (e.g., a block older than the pruning window). If the node returns block_not_found and you need to validate it, you will have to fetch the block from a trusted source or run a full node.

Conclusion

The choice between full and pruned storage is a classic trade‑off between decentralization and resource efficiency. Use full mode when you need complete, independent verification; use pruned mode when disk space and sync speed are primary concerns. Follow the configuration and validation steps above to set up the mode that matches your constraints.