Choosing the wrong Flare node configuration can mean the difference of thousands of dollars if not chosen correctly. What is the true difference between archival and pruned nodes? As I have discovered the hard way, there are three primary configurations that I consider. They are: Non Pruned (“archival/full history”) - > 5.5 TB database (on Flare & growing) - All data for specialised use cases - Multiple weeks to sync/bootstrap - ✅ CAN query blocks, receipts & logs/events since genesis - ✅ CAN query historical state (this means requesting balance/contract view function/contract code/merkle proofs/etc at a specific block in the past, all the way back to genesis) - ✅ CAN query current state (ie. get current vote power, account balance, etc) Pruned - <1 TB database (on Flare & growing) - Most data for most use cases - 1-2 weeks to sync/bootstrap - ✅ CAN query blocks, receipts & logs/events since genesis - ⚠️ CAN query historical state but only at commit intervals meaning only a small subset of historical state may be queried. Configurable with `commit-interval`, default every 4096 blocks. Pruned + State Sync - <100 GB database (on Flare & growing) - Essential data suitable for validators and basic RPC usage - Hours to sync/bootstrap - ❌CANNOT query blocks, receipts & logs/events since genesis. Limited to block that node started syncing and `state-sync-min-blocks` parameter. - ⚠️ CAN query historical state but only at commit intervals but significantly more restricted to recent blocks. - ✅ CAN query current state (ie. get current vote power, account balance, etc) So, for validators or hobbyists who want their own RPC node, a PRUNED node with STATE SYNC ENABLED is ideal. Allows validation of the network and submission of transactions (and reading current network state) with minimal hard drive space required. For most analytical indexing that rely on receipts, event logs and blocks since genesis, a PRUNED node with STATE SYNC DISABLED is suitable. For advanced debugging and deep analytics a NON PRUNED node with STATE SYNC DISABLED is recommended. Now, if it is still unclear to you the difference between archival nodes and pruned nodes (as it was for me), let me explain… Pruned nodes do not have the full freedom to use function like: - eth_getBalance(address, block) - eth_getStorageAt(contract, key, block) - eth_call(contractCall, block) (ie. contract.getBalance({ blockNumber })) … and an number of other similar functions. Notice how they provide a block to query? An archival node can provide any existing block number and retrieve the respective data like an accounts balance, a contracts state or code at a particular block. The other two nodes have these functions available, but as mentioned, the block queryable is limited to the committed tries, which by default is every 4096 blocks. So there is a massive span of data missing, even more so for state synced nodes. If you are so willing, and the data is valuable to you, you can query data at these intervals but you will need to calculate which state (blocks) are available using some math and/or debug_getAccessibleState. So before you spin up an archival node, know that most people will never need it. It costs more than a flying donkey to host on cloud servers and is really limited to usage in blockchain explorers, deep historical indexing of state (as described above) or advanced debugging. As an example, a pruned node (no state sync), will typically suffice for most users using @SubQueryNetwork Indexer SDK. I feel the need to reiterate it: this node configuration DOES provide all event logs, transactions etc. You can for example index every transfer of an ERC20 token ever made for any token or every single claim of FTSO rewards ever made. I hope this clears up anyones confusion over the difference between these node configurations. I would recommend avoiding archival nodes unless you certainly need its functionality. Always try a pruned (no state sync) node before an archival node for most development/analytics purposes or a pruned (state synced) node for basic RPC usage or validators.