We measured the datadir size of the fleet's nodes eight times from 2026-11-14 19:20 UTC to 2026-11-15 04:07 UTC (8.79 hours), with du -sx at the lowest I/O priority. On Apothem, nodes at the tip grew between 11 and 55 MB per hour, except one: the xOneC snap node grew 237 MB per hour, about 15 times geth-XDC. We filed that as xOneC#97 (private repository). On net2040, almost every node grew about 1.6 MB per hour.
Hosts are named A, B and C. For the method see the fleet snapshot. For total sizes see Apothem datadir sizes and disk planning.
How fast does each datadir grow on Apothem?
The chain advanced 15,354 to 15,355 blocks in the window. Growth is the last size less the first size.
| Host | Node | Growth (bytes) | MB per hour | Bytes per block | Size at 04:07 UTC (GB) |
|---|---|---|---|---|---|
| C | xOneC snap | 2,081,816,576 | 236.9 | 135,588 | 53.13 |
| B | besu-xdc snap (Bonsai) | 479,535,104 | 54.6 | 31,230 | 30.01 |
| B | nethermind-xdc hybrid | 319,307,776 | 36.3 | 20,795 | 23.98 |
| C | nethermind-xdc hybrid | 294,858,752 | 33.6 | 19,204 | 23.76 |
| C | xOneRS snap | 259,903,488 | 29.6 | 16,927 | 75.37 |
| B | geth-XDC snap (reference) | 141,373,440 | 16.1 | 9,207 | 154.27 |
| C | xOnePy snap | 136,196,096 | 15.5 | 8,870 | 31.26 |
| B | reth-xdc full | 97,669,120 | 11.1 | 6,361 | 161.71 |
Left out of this table:
- erigon-xdc minimal (host C) reached the tip during the window, so its growth includes sync.
- reth-xdc minimal (host C) was about 45,000 blocks behind and catching up (19,295 blocks in the window). It grew 172,150,784 bytes. See its catch-up.
- xOneGo snap (host B) has only three samples under its correct label. See the pid-lookup correction in memory per XDC client.
What about the xOneC outlier?
The xOneC Apothem snap node grew in every one of the eight samples. A later read-only check put the rate at about 295 MB per hour (04:07 to 04:36 UTC). Almost all of the data is in its MDBX file, chain.mdbx, at 52.7 GB. The four xOneC nodes on net2040 grow like every other client, so the excess shows only on the busier chain. We do not know the cause yet. Two candidates are freed pages that the database cannot reuse while an old reader holds them, and history that the snap window does not prune. The issue asks for the table and free-list statistics first.
How fast does each datadir grow on net2040?
The chain advanced 7,069 to 7,073 blocks. Most nodes grew 13.8 to 15.4 MB, about 1.6 MB per hour or about 2,000 bytes per block:
| Host | Nodes | MB per hour | Bytes per block |
|---|---|---|---|
| A | xOneRS full and archive; xOneTS full; xOnePy snap and minimal; xOneC full, archive, snap and minimal | 1.6 to 1.7 | 1,946 to 2,176 |
| B | geth-XDC full; xOneRS full; reth-xdc archive; nethermind-xdc ×3 | 1.6 to 1.7 | 1,950 to 2,087 |
| C | xOneRS fast and minimal | 1.6 | 1,950 |
| C | nethermind-xdc full and archive; reth-xdc full | 1.2 to 1.4 | 1,500 to 1,745 |
| C | besu-xdc snap (Bonsai) | 0.2 | 259 |
| B | besu-xdc full (Bonsai) | 0.0 | 8 |
Several nodes of one client grew by exactly the same number of bytes in every mode: the four xOneC nodes by 13,758,464 each, and the xOneRS full and archive nodes by 13,795,328 each. So in this window the growth did not depend on the sync mode. The two besu-xdc nodes barely grew; the snap node's size also went down between some samples. We did not check why.
How should these numbers be read?
- 8.79 hours is short. A database can grow in steps and reuse space later, so one window does not give a daily rate. Multiply by 24 only as a first guess.
ducounts allocated blocks. A database file that is preallocated, or that has free pages inside, shows its full size.- Per-block numbers depend on the chain's load. net2040 blocks are mostly small; Apothem carries more traffic.
- We read the sizes at the lowest I/O priority on hosts that also run other work. We did not stop or change any node.
Frequently asked questions
How much disk does an XDC Apothem node add per day?
In this window, between about 0.27 and 1.3 GB per day for the nodes at the tip (11 to 55 MB per hour), except the xOneC snap node at about 5.7 GB per day. One window of 8.8 hours is not a daily measurement.
Which client's datadir grew the slowest on Apothem?
reth-xdc full, at 11.1 MB per hour, then xOnePy snap and geth-XDC snap at about 16 MB per hour.
Why does the xOneC Apothem node grow so fast?
We do not know yet. The growth is in its MDBX file. xOneC#97 tracks it.
Does the sync mode change how fast the datadir grows on net2040?
Not in this window. Each client's nodes grew by the same number of bytes in every mode.
Sources
- Fleet probe time series, 2026-11-14 19:20 UTC to 2026-11-15 04:07 UTC,
du -sx --block-size=1withnice -n 19andionice -c3, andeth_blockNumber(read-only). - xOneC#97 (private repository).
This article describes the source and evidence at its review date. Check the linked repository for current implementation and qualification status.
Explore the engineering evidenceEdit this page on GitHub opens the Markdown source (content/blog/xdc-datadir-growth-rate/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.