Graph model

A graph database is specifically designed to store data as nodes and edges (relationships between nodes). With this model, connections are front and center, making it easier (and often faster) to query highly connected datasets, like social networks, planning and supply chain relationships, recommendation engines, or fraud detection graphs.

When using SurrealDB as a graph database, you typically care about both the entities in a system and how they relate to each other. It might be a user that “follows” another user, a product that “belongs” to a category, or a web page that “links to” another page. These relationships are first-class citizens, rather than just foreign keys or nested objects. That enables powerful, intuitive traversal-based queries that reflect real-world systems.

But how do you “think” in a graph database? Instead of focusing on how to break data into tables (relational) or embed data in documents (document model), you concentrate on expressing data as nodes and defining the edges that describe relationships. This mindset puts the connections at the core of your design: each data point is a node with properties, and edges hold properties too, representing the context or metadata about those relationships.

Core concepts of graph-oriented modeling

In any graph database, you deal with three fundamental elements:

• Nodes (Vertices): Represent main entities or “things”. In a social network for example, nodes might be people. In a knowledge graph, nodes might be concepts. In a product recommendation engine, nodes might be items or customers.

• Edges: Represent relationships between nodes. These could be follows, buys, likes, friend_of, in_category, etc. They often include properties like timestamps or weights.

• Properties: Both nodes and edges can contain key-value pairs (properties). For a user node, properties might be name or age. For a likes edge, a property might be strength to indicate how strong the affinity between users is.

When you think in a graph, the modeling process shifts toward identifying the main entities in your application (the nodes) and how they relate to one another (the edges). Rather than flattening these relationships into foreign keys or embedding them in nested structures, you give them explicit representation and, often, explicit properties.

Modelling data as a graph

How this works in practice in most graph databases is through "semantic triples", which describe a graph in a three-part structure:

• subject -> predicate -> object

Or:

• node -> edge -> node

Another way to think about this is in terms of nouns connected by verbs, such that it forms a sentence.

• noun -> verb -> noun

Or:

• person -> order -> product

Where to go next

The guides in this section break down how SurrealDB implements these ideas in practice:

• Creating relations: RELATE, edge tables, in / out, schema with TYPE RELATION, and edge cases such as relations before records exist.

• Graph traversal: arrow syntax, traversing from record IDs, flattening behaviour, graph paths in schema, and using Surrealist’s Explorer.

• Recursive traversals: @.{n} paths and nested shapes along a graph.

• Record links vs graph relations: when to use each, metadata on edges, weighting, and delete behaviour.

• Social network patterns: friendship-style edges, bidirectional queries, and interaction weighting examples.

• Knowledge graph patterns: orienting nodes and edges for knowledge-style and industry schemas.

For statement-level reference and deeper query details, see:

• The RELATE statement

• Idioms (including recursive paths)

• The SurrealDB Fundamentals course

• Aeon's Surreal Renaissance, chapters 5 to 8 in particular