Store Growth, Relationship Density, Index Size, Transaction Log Growth, and Capacity Forecasting

AtlasMart’s graph is healthy today, but data volume grows 4% each week, one category hub’s degree doubles every campaign, and transaction logs occasionally consume unexpected disk. Capacity planning cannot be “count nodes and buy 2× RAM.” Graph shape, indexes, log retention, write rate, working set, backups and failure/maintenance headroom all consume different resources.

Learning outcomes

Reproducible lab baseline

1. Store size is multiple stores

Neo4j persists node/relationship/property data, native indexes, Lucene-backed indexes, transaction logs and other database files. neo4j-admin server memory-recommendation reports useful aggregate data/native-index and Lucene-index sizes for memory planning. File-system snapshots add disk evidence. Do not infer page-cache requirement from “database folder size” without knowing which files are served by page cache versus OS/Lucene/vector mechanisms.

docker exec atlasmart-neo4j neo4j-admin server memory-recommendation
# Optional inside-container filesystem snapshots; paths depend on distribution/container mapping:
docker exec atlasmart-neo4j sh -lc 'du -sh /data/databases/neo4j /data/transactions/neo4j 2>/dev/null || true'

2. Degree distribution predicts traversal pressure better than average count

A graph with one million evenly connected nodes behaves differently from one where one influencer/product/category has five million incident relationships. Measure degree distribution on labels/types relevant to critical queries.

CYPHER 25
MATCH (c:ObsCustomer)
OPTIONAL MATCH (c)-[r:OBS_VIEWED]->()
WITH c, count(r) AS degree
RETURN count(*) AS customers,
       min(degree) AS minDegree,
       percentileCont(degree, 0.50) AS p50Degree,
       percentileCont(degree, 0.95) AS p95Degree,
       max(degree) AS maxDegree;

3. Index footprint is a write/storage tradeoff

Every index can accelerate supported predicates but adds storage, population/build work and write maintenance. Chapter 9 already established evidence-based index selection. Capacity planning extends that discipline: keep index inventory, store footprint and build headroom with the query evidence that justifies each index.

CYPHER 25
SHOW INDEXES
YIELD name, type, entityType, labelsOrTypes, properties, state, populationPercent
RETURN * ORDER BY type, name;

4. Transaction logs are recovery/replication data, not monitoring logs

Transaction logs record database changes. They are separate from debug/query/security logs. Current configuration includes rotation size and retention policy; the documented default retention policy is 2 days 2G, but production must choose retention based on backup/recovery/cluster needs and disk capacity. Neo4j explicitly does not support manually deleting transaction-log files.

CYPHER 25
SHOW SETTINGS
YIELD name, value
WHERE name IN ['db.tx_log.rotation.size','db.tx_log.rotation.retention_policy']
RETURN name, value ORDER BY name;

5. Build timestamped snapshots

6. Forecast cautiously

A simple linear forecast is useful as an alerting/planning tool only when its assumptions are explicit. Campaigns, imports, index builds and retention changes break linearity. Use it to ask “when should we revisit capacity?” rather than to promise an exhaustion date.

from statistics import mean
from datetime import date, timedelta

# Replace with measured daily MiB snapshots from your environment.
points = [
    (date(2026, 9, 1), 820),
    (date(2026, 9, 2), 836),
    (date(2026, 9, 3), 851),
    (date(2026, 9, 4), 870),
    (date(2026, 9, 5), 888),
]
deltas = [points[i][1]-points[i-1][1] for i in range(1,len(points))]
daily_growth = mean(deltas)
current = points[-1][1]
capacity = 2048
headroom = capacity-current
print({"avg_daily_growth_mib": round(daily_growth,2),
       "current_mib": current,
       "headroom_mib": headroom,
       "linear_days_to_capacity": round(headroom/daily_growth,1)})
# This is a planning model, not a forecast guarantee; growth is rarely perfectly linear.

7. Headroom includes recovery and maintenance

8. Capacity acceptance questions

Production judgment

Summary and next step

You can now connect graph/store/log growth to resource headroom. Lesson 5 turns the chapter into an operational runbook and tests whether each diagnosis/remediation survives evidence.

Authoritative references

• Current Neo4j versions — Current Neo4j 2026.07.1 and 5.26.30 LTS release snapshot.
• Monitoring overview — Current monitoring surfaces: logs, metrics, query/transaction management, connections, jobs, and reports.
• Metrics — Enterprise metrics architecture and supported export surfaces.
• Essential metrics — Server, Neo4j, cluster, and workload signals that require correlation rather than single-metric tuning.
• Metrics reference — Current page-cache, JVM, CPU, file-descriptor, transaction and store metric names.
• Logging — Current neo4j/debug/http/gc/query/security log behavior and edition boundaries.
• Show and terminate transactions — Current SHOW TRANSACTIONS fields for locks, wait time, memory, page hits/faults, runtime, indexes, and status.
• Manage queries — Current query visibility through transaction management rather than legacy dbms.listQueries().
• Memory configuration — Heap, page cache, native memory, transaction limits, and memory-recommendation guidance.
• Disks, RAM and other tips — Page-cache warmup, disk behavior, and operating-system considerations.
• Performance — Performance topics spanning memory, disks, statistics, execution plans, Bolt threads, and filesystem tuning.
• Show configuration settings — Current SHOW SETTINGS syntax and self-managed server scope.
• Transaction logs — Transaction-log location, rotation, retention, pruning, and capacity implications.
• Query tuning and PROFILE — Execution-plan evidence for rows, database hits, memory, access paths, and operator shape.
• Python driver performance — Driver-side timing, database selection, result consumption, and application/database boundary considerations.