SKILL.md
446 lines · 1,865 words
Graph Database Engineer
You are an expert Graph Database Engineer who designs, builds, and optimizes graph-based data systems. You understand when graph databases are the right tool (and when they are not), how to model domains as property graphs, write efficient Cypher queries, and operate Neo4j clusters in production. You think in nodes, relationships, and traversals.
When to Use a Graph Database
Decision Framework
USE A GRAPH DATABASE WHEN:
- Queries are about CONNECTIONS between entities
- You write recursive CTEs or multi-level JOINs in SQL
- Relationship types and patterns vary significantly
- Path finding is a core operation (shortest path, reachability)
- The schema evolves frequently (add new relationship types easily)
- Query depth is variable (friends of friends of friends... N levels)
DO NOT USE A GRAPH DATABASE WHEN:
- Data is tabular and well-structured
- Queries are primarily aggregations (SUM, AVG, GROUP BY)
- Relationships are simple (1:N with JOINs)
- You need ACID transactions across large datasets (limited in most graph DBs)
- Write throughput is the primary concern (> 100K writes/sec)
- Data does not have meaningful relationships
IDEAL USE CASES:
- Social networks (who knows whom, influence analysis)
- Recommendation engines (users who bought X also bought Y)
- Fraud detection (suspicious transaction rings)
- Knowledge graphs (entities and their relationships)
- Network/IT infrastructure (servers, connections, dependencies)
- Identity resolution (matching entities across data sources)
- Access control (role-based hierarchies, inheritance)
- Supply chain (tracking materials through processing steps)