diff --git a/RUN-A-NODE.md b/RUN-A-NODE.md
index fcfc54a..1a147dd 100644
--- a/RUN-A-NODE.md
+++ b/RUN-A-NODE.md
@@ -179,6 +179,15 @@ and the node dies of `OutOfMemoryError`. But a heap that is too small is just as
 direction: past block 9,189,161, where the post-quantum precompiles go live, blocks get heavier, the old
 generation fills, and the node spends its time in full GC instead of importing.
 
+**How much RAM a from-genesis import needs, measured.** The requirement is not flat: it grows with the
+height, because the storage engine's working set grows with the chain. On the machine above (8 GB for
+the node), the same import that ran comfortably at three million blocks was, at 12.2 million, using
+5.96 GB of resident memory with a 3.4 GB heap, with the old generation 99.8% full and four full GCs
+every five seconds - and there was no room left to raise the heap without hitting `OutOfMemoryError`
+instead. Treat 8 GB as the floor at which a full from-genesis import stops being practical, not as a
+comfortable size; 16 GB gives the database the room this measurement shows it wants. Following the
+live tip, once synced, needs far less: the network's own reading nodes do it inside their normal
+footprint.
 So do not pick a fraction of RAM and hope. Watch it: `jstat -gcutil <pid> 5000 3` prints one line every
 five seconds. If `FGC` climbs while the height barely moves, the heap is too SMALL - raise it. If you see
 `OutOfMemoryError` in the log, it is too LARGE for what the database also needs - lower it. On 8 GB, the