Graph Database

Graph databases store entities and relationships in the form of nodes and edges, and natively support multi-hop reasoning.

Graph databases store relationships as first-class citizens, enabling multi-hop relationship queries to be completed in milliseconds via graph traversal algorithms without the need to perform costly multi-table JOIN operations.

Using a graph database as the external memory carrier (rather than a vector store) makes 'what this player prefers and what they have asked' queryable structured facts along edges, thereby maintaining coaching continuity across matches.

Graph databases are not meant to replace SIEM but to serve as its relationship layer, reorganizing the discrete events produced by SIEM into a traversable attack graph.

Answers to questions like revision lists and counts are not in any text but in the graph structure, which constitutes a reason to use a graph database, though strictly speaking it is not a failure of retrieval.

On 200 test projects that appeared clean on the surface but actually hid risks, the method that only looks at the project's own records had a detection rate of 0%, while Khoj's graph method reached a detection rate of 81% with zero false positives.

The most underrated use of graph databases in agent systems is that the traversal result is itself structurally an explanation, with provenance obtained for free.

In flight delay propagation models, slack should be an edge attribute rather than a node attribute, because vulnerability belongs to the handoff between flights.

Although relational databases support JOIN, queries over multi-hop paths of variable depth require recursive CTEs, and their performance and expressiveness are inferior to those of graph databases.

Using a graph database to explicitly model relationships avoids stuffing large hospital directories and allergy guidelines into the LLM context window, thereby reducing the risk of hallucination.

The value of a persistent memory system lies in storing important information externally (such as in a vector store or graph database) and re-injecting only the most relevant fragments into the context window when needed, thereby breaking through the window capacity limit and retaining information across sessions.

Traditional relational databases require multiple JOIN operations to express multi-hop associations, and performance degrades sharply as association depth increases; graph databases store relationships as first-class citizens, so multi-hop query latency is approximately linear in path length.

Engram represents a new memory superseding an old one via a SUPERSEDES edge; old memories are marked superseded but not deleted, and recall filters to active status by default.

The root of the performance gap is index-free adjacency: in a graph database each node points directly to its neighbors, so traversing along edges only requires pointer hops, and the cost depends on the actual size of the graph visited rather than the size of the whole table.

The author believes graph databases are not a nice-to-have for anti-money-laundering, because fraud itself is graph-shaped.

Structured storage of opinions often uses graph databases or time series databases to support multi-dimensional queries by person, topic, and time range.

An organizational hierarchy is fundamentally a rooted tree or directed acyclic graph in terms of data structure; querying multi-level reporting chains in relational databases requires recursive CTEs whose performance degrades, whereas graph databases such as Neo4j and Amazon Neptune have performance advantages in path traversal