Production Concerns

Operating a graph DB at scale:

Capacity planning:

• Single-machine fastest. ~100M-10B edges typical max.
• Beyond: distributed compute (slower per-query).
• Memory matters: Neo4j caches everything in page cache; SSD only.

Schema evolution:

• Adding a label: easy.
• Removing a property from millions of nodes: scan + update, slow.
• Batch refactoring tools (apoc.refactor.*).

Query optimization:

• EXPLAIN / PROFILE shows query plan.
• Force indexes via hints (planner sometimes wrong).
• Limit traversal depth (*1..5 not *).

Hot spots:

• Super-nodes (millions of edges): kill performance.
• Solutions: filter edges by type/property, sample, use approximation.

Backup:

• Online backup (read-consistent snapshot).
• Tar full filesystem for offline.
• Restore = test regularly.

Monitoring:

• Page cache hit rate (>90% target).
• Transaction latency p99.
• Active locks (long write txns block readers).
• WAL size + checkpoint frequency.

Multi-tenancy:

• One graph per customer (DB per tenant).
• Or shared graph with tenant_id label.
• Isolation: separate DBs strongly preferred.

Common pitfalls:

• Cartesian explosion in queries (MATCH (a), (b) with no relationship → A x B rows).
• Missing indexes → full scan on large label.
• Long transactions → memory pressure.
• Improper variable-length pattern (* without bound) → OOM.

Backup + recovery:

• WAL replay on restart.
• Online checkpoint regularly.
• Snapshot to S3 for DR.

Replication:

• Causal cluster (Neo4j): consensus-based replication for reads.
• Single leader for writes; read replicas for scale.
• Failover via Raft.

Don't:

• Roll your own for production.
• Migrate from SQL to graph without measuring (the join cost is real, but B-tree indexes are also fast).

Do:

• Use Neo4j / Memgraph / TigerGraph for property graph workloads.
• Use Apache Jena / Stardog / GraphDB for RDF.
• Consider NetworkX for prototyping in Python.