Every xOne client snap-synced the same Apothem state, yet their datadirs differ by a factor of five. Issue #149 records 13 GB for the earlier Go line (xOneGo), 29 GB for xOnePy, 44 GB for xOneC, 47 GB for xOneTS and 72 GB for xOneRS on 2026-11-14. A fresh read-only count on 2026-11-15 gives similar numbers and shows that the xOneC datadir grows much faster than the others. The causes are not measured yet; the issue lists likely ones.

For how each client lays out its store, see storage in xOne. For disk planning, see disk planning.

What did each client snap-sync?

The same state for all of them: 327,356 accounts, 158,076,350 storage slots and 39,087 codes, with a state root equal to geth-XDC at the pivot (issue #149).

How big is each datadir?

Two sources, in two units. Issue #149 gives sizes as recorded on 2026-11-14. Our fresh count is du -sx --block-size=1, in bytes, read-only, on the team's own followers.

REFERENCE TABLEScroll to explore all columns →
Client Issue #149 (2026-11-14) Bytes, 2026-11-15 03:31 UTC Change since 2026-11-14 19:20 UTC
xOneGo (earlier Go line) 13 GB 9,894,952,960 -38,871,040
xOnePy 29 GB 31,246,376,960 +126,693,376
xOneC 44 GB, "grows ~1 GB/h" 52,983,132,160 +1,938,124,800
xOneTS 47 GB not measured (node outside the probe) -
xOneRS 72 GB 75,234,598,912 +126,730,240

The "change" column is the difference between the 2026-11-14 19:20 UTC probe and the 03:31 UTC count, 8 h 11 min apart. Over that window xOneC grew by about 237 MB per hour, xOneRS and xOnePy by about 15 MB per hour each, and the xOneGo datadir shrank slightly. The xOneC rate here is lower than the "~1 GB/h" in the issue; both are single observations.

Why do the sizes differ?

Issue #149 lists likely causes and marks them "NOT measured yet":

  • xOneRS: trie nodes persisted by path, including leaf rows (TrieNodes), on top of the flat rows.
  • xOneTS: snap staging tables kept after the install, and the SQLite file not vacuumed (about 10 GB).
  • xOneC: trie nodes keyed by hash and never pruned; the node store is not pruned.
  • xOnePy: flat state plus a persisted trie, with block history pruned to a window.
  • xOneGo: flat state only, with an anchored snap.

The issue plans a per-table measurement for each client (for xOneRS: xone db stats, from PR #419), then a fix for each excess that is waste, checked by parity and a new measurement.

Why does it matter?

Issue #149 gives the reason: these nodes are meant to become long-running Apothem validators, and on 2026-11-14 a shared data disk filled up and a neighbouring validator stopped on its low-disk guard and was penalised. Mainnet state is far larger than Apothem's.

How do other clients describe their storage?

REFERENCE TABLEScroll to explore all columns →
Client What its documentation states Network
besu A Bonsai snap full node takes about 1.14 TB, as stated in Besu data storage formats Ethereum mainnet
nethermind Flat DB, mainnet about 260 GB, as stated in Flat DB in Nethermind, 2026-04-07 Ethereum mainnet

These are Ethereum mainnet figures and do not compare with Apothem. The fork clients' Apothem datadirs on the same fleet are in the fleet snapshot.

Frequently asked questions

How big is an xOne Apothem datadir after snap sync?

Between about 10 GB (xOneGo) and 75 GB (xOneRS) in our counts of 2026-11-14 and 2026-11-15. Issue #149 records 13 to 72 GB for the five clients on 2026-11-14.

Which xOne client grows fastest on Apothem?

xOneC: about 237 MB per hour over eight hours in our count, against about 15 MB per hour for xOneRS and xOnePy. Issue #149 names an unpruned trie node store as the likely cause.

Is the size difference a correctness problem?

No: every client reached the same state root as geth-XDC at the pivot. The difference is how much each store keeps, and part of it may be waste. Issue #149 tracks the measurement and the fixes.

How do I measure my own datadir?

du -sx --block-size=1 <datadir> gives the total. For xOneRS, xone db stats gives the per-table MDBX sizes and the segment sizes.

Sources