Memgraph Model Graph Data

Graph Data Modeling for Memgraph

Memgraph uses the Labeled Property Graph (LPG) model: nodes and relationships both carry properties (key-value pairs), and nodes can have multiple labels.

Core concepts

Four components

1. Nodes - entities with zero or more labels
2. Relationships - directed edges with exactly one type (immutable after creation)
3. Properties - key-value pairs on nodes and/or relationships
4. Labels - classify nodes; enable indexed lookups

(:Person:Student {name: "Alice", age: 20})-[:STUDIES {grade: "A"}]->(:Subject {name: "Math"})

Key properties of LPG

• Flexible, dynamic schema - add labels/properties anytime without migrations
• Relationships are first-class (not inferred via JOINs)
• Optimized for multi-hop traversals
• In-memory storage means property types directly affect RAM

Design methodology

Step 1: Define requirements

Write down what the database is for - use case drives the model. Ask:

• What entities exist?
• How do entities relate to each other?
• What questions will the graph answer?
• What properties are needed, and where should they live?

Step 2: Identify nodes and relationships

Nouns become nodes. Group similar entities under labels. Verbs become relationships. Name them as actions: KNOWS, WORKS_ON, BELONGS_TO.

Step 3: Place properties strategically

Step 4: Validate with real queries

Write the queries you'll actually run. Use PROFILE to check the query plan. If a query is slow or awkward, revisit the model.

Property vs relationship - decision framework

Use a property when

• The value is unique/specific to that node
• It's rarely used to find related entities
• It doesn't represent a shared concept

(:Product {name: "Milk", price: 2.99, expirationDate: "2024-01-01"})

Use a relationship when

• The data connects entities and can be shared across nodes
• You frequently query "which other nodes share this value?"

Anti-pattern - categories as array property:

(:Product {name: "Milk", categories: ["Dairy", "Organic"]})

This forces scanning every node's array to find shared categories.

Pattern - categories as nodes:

(:Product {name: "Milk"})-[:BELONGS_TO]->(:Category {name: "Dairy"})
(:Product {name: "Milk"})-[:BELONGS_TO]->(:Category {name: "Organic"})

Query for related products:

MATCH (:Product {name: "Milk"})-[:BELONGS_TO]->(c)<-[:BELONGS_TO]-(other:Product)
RETURN other.name;

Supernode warning

When a shared-value node accumulates too many relationships (e.g., a Country node connected to millions of Person nodes), it becomes a supernode - traversals through it are expensive. Strategies:

• Keep high-cardinality shared data as properties when traversal isn't needed
• Partition supernodes (e.g., Country + Region hierarchy)

Anti-patterns and patterns

Knowledge graph modeling

A knowledge graph encodes domain knowledge in the graph structure so the graph itself is "readable as sentences."

Evolution example

Weak model - skills stored as property arrays:

MATCH (p:Person)-[:WORKS_ON]->(t:Task)
WHERE all(skill IN t.Skills WHERE skill IN p.Skills)
RETURN *;

Knowledge is in the query, not the graph.

Strong model - skills as nodes with semantic relationships:

(:Person)-[:HAS]->(:Skill)
(:Task)-[:NEEDS]->(:Skill)
(:Person)-[:WORKS_ON]->(:Task)

Find sufficient skills:

MATCH (p:Person)-[:HAS]->(s:Skill)<-[:NEEDS]-(t:Task)
WHERE exists((p)-[:WORKS_ON]->(t))
RETURN p.name, collect(s.name);

Find skill gaps:

MATCH (p:Project)-[:REQUIRES]->(s:Skill)
OPTIONAL MATCH (person:Person)-[:HAS]->(s)
WITH p, s, collect(person) AS people
WHERE size(people) = 0
RETURN p.name AS project, collect(s.name) AS missingSkills;

GraphRAG integration

1. Embed a question → vector search → find a pivot node
2. Expand from pivot (e.g., 2-hop neighborhood):

   MATCH path=(pivot:Project {name: "Data Pipeline"})-[*..2]-(n)
   RETURN path;
   

3. Pass subgraph context to LLM

Memgraph-specific modeling considerations

Memory estimation

RAM ≈ nodes × 204B + edges × 154B + properties + indexes

• For 50+ indexes: add ~20% overhead
• Query multiplier: 1.5x (basic) to 2x (algorithms)
• Use the storage calculator

Data type choices for memory

Indexing during modeling

• Create indexes BEFORE large imports on MATCH/MERGE key properties
• Label-property indexes are NOT auto-created (unless flag enabled)
• Uniqueness constraints do NOT create indexes - add them separately
• Run ANALYZE GRAPH after data load

Storage modes

Switch for bulk loading:

STORAGE MODE IN_MEMORY_ANALYTICAL;
-- bulk import here
STORAGE MODE IN_MEMORY_TRANSACTIONAL;

Create a manual snapshot before switching back: CREATE SNAPSHOT;

CSV import workflow

1. Design the model from CSV columns

Map CSV columns to node properties. Identify which columns represent entities (nodes) vs connections (relationships).

2. Create indexes before import

CREATE INDEX ON :Person;
CREATE INDEX ON :Person(name);

3. Load and transform

LOAD CSV FROM "/path/data.csv" WITH HEADER AS row
CREATE (:Person {
  name: row.Name,
  age: toInteger(row.Age),
  dob: date(row.Date_of_Birth)
});

CSV values are always strings - convert with toInteger(), toFloat(), date(), toBoolean().

4. Create relationships

MATCH (a:Person {name: "Alice"}), (b:Person {name: "Bob"})
MERGE (a)-[:FRIENDS_WITH]->(b);

Use MERGE (not CREATE) to avoid duplicate relationships. Use LIMIT and WHERE a <> b to control combinatorial explosion.

5. Batch large imports

USING PERIODIC COMMIT 1000
LOAD CSV FROM "/path/data.csv" WITH HEADER AS row
CREATE (:Node {id: row.id, name: row.name});

LPG vs RDF

Choose LPG when: real-time analytics, schema flexibility, graph algorithms, developer ergonomics.

Choose RDF when: linked data integration, semantic reasoning, ontology required.

Checklist for a good data model

• Clear node labels that group similar entities
• Well-named relationship types (verbs: KNOWS, OWNS, BELONGS_TO)
• Properties on the right entity (node vs relationship vs separate node)
• No unnecessary data duplication
• Temporal and numeric types (not strings) for dates and numbers
• Indexes on properties used in MATCH/WHERE
• No supernodes without mitigation strategy
• Validated with PROFILE on real queries
• Memory estimate fits available RAM