Discord questions

Advantages

• natural representation of relationships

• effective traversal

• flexible schema

• expressive query language like cypher

Disadvantages

• massive graphs can become unclear and difficult in distributed processing

• for large scale reporting or olap style queries relation might perform better

• teams would need to adapt, difficult to adapt for already existing complex db architecture

• less mature compared to established relational systems

Perhaps that the node is a thing

Further:

• avoid duplicates by using merge in cypher

• assign a meaning full label

• if possible add directly relation for integration in graph

No

• speed in querying connected entities e.g. users being friend in relational vs. graphDB -> Because when building on scale it might be an option I haven’t considered before for use cases

• storing relationships as first class citizens: relational have relationships implicit, graphdb explicit and efficient traversable. Who bough what product can be handled natural and performantly -> cool for recsys

Native:

• built for storing and processing graphs

• uses native graph storage

• query engine uses index-free adjacency

• faster

• e.g. neo4j

Non-native:

• built on top of non graph storage e.g. relational

• maps graph structures onto other storage models

• requires lookups on join to simulate traversal

• slower for complex graphs

RDBMS

• tables wiht rows and columns

• foxed schema

• represented via foreign keys and joins

• sql

• structured data,

• poor performance with deep joins

• finance, erp

Graphdb

• nodes and relationships

• schema optional or flexible

• relationchips as first class relationships

• cybpher, aql

• less suited for heavy tabular aggreagtion

• social networks, recsys

• Relational DBs use fixed schemas, tables, and foreign keys; ideal for structured, transactional data.

• Graph DBs model entities and relationships directly; ideal for connected data and traversals.

• NoSQL DBs (in general) offer schema flexibility and horizontal scalability, suited for large, varied, or evolving datasets.

• A graph model with:

  • Nodes: Entities with properties

  • Relationships: Directed edges between nodes, also with properties

  • Labels: Categorize nodes (can have multiple)

  • Properties: Key-value pairs on both nodes and relationships

• Supports schema-optional modeling and efficient traversal via index-free adjacency.

• Labels:

  • Categorize nodes into types or roles (e.g., :User, :Product)

  • Help organize data and optimize query performance

  • A node can have multiple labels

• Properties:

  • Store data values as key-value pairs on nodes or relationships (e.g., name: "Alice", since: 2020)

  • Add detail to the graph’s elements

Why they exist:

• Labels provide structure and fast lookup

• Properties store the actual attributes and metadata needed for queries and analysis

• Why more efficient:

  • Use index-free adjacency: nodes directly reference connected nodes

  • No need for costly JOIN operations

  • Designed for traversal-based queries (e.g., shortest path, friends-of-friends)

• When faster:

  • For deeply connected data and recursive queries

  • When querying complex relationships (e.g., social networks, fraud detection)

  • In real-time applications where quick relationship lookups are critical

Summary:

Graph DBs outperform relational DBs when the query involves many relationships or multiple hops through connected data.

• Neo4j uses Cypher – a declarative graph query language designed specifically for querying and updating property graphs.

• ArangoDB uses AQL (ArangoDB Query Language) – a SQL-like language that supports graph, document, and key-value queries across its multi-model architecture.

• Nodes: Represent entities, can have key-value properties

• Relationships: Directed edges connecting nodes, also support properties

• Labels: Categorize nodes by type or role (e.g., :User, :Movie)

• Properties: Stored on both nodes and relationships as flexible key-value pairs

• Schema-optional: No rigid schema required, supports dynamic structure

• Efficient for connected data: Faster traversal without expensive JOINs

• Index-free adjacency: Direct references between connected nodes

• Flexible schema: Schema-optional, easily evolves with changing requirements

• Ideal for recursive/deep queries: E.g., social networks, recommendations, fraud detection

• Natural modeling: Graphs mirror real-world networks more intuitively than tables