Graph databases

Graph databases Neo4j, Amazon Neptune, Apache TinkerPop (Gremlin) and Dgraph are reachable through the same model API as the SQL dialects. findAll, create, update, destroy, where operators, associations and include all work — the graph dialects implement the Dialect contract and compile those calls into Cypher, Gremlin or Dgraph DQL. You do not hand-write graph queries for standard operations. This is different from the NoSQL stores, which expose each engine's own native API instead of the model layer. Dialect name | Class | Language | --- | --- | --- | neo4j | Neo4jGraphDialect | Cypher | gremlin | GremlinGraphDialect | Gremlin (TinkerPop) | neptune | GremlinGraphDialect | Gremlin (Amazon Neptune) | dgraph | DgraphGraphDialect | Dgraph DQL + JSON mutations | All four are registered with the shared DialectRegistry when the package loads, so dialect: 'neo4j' resolves like any built-in. A model's name becomes the node label; its attributes become node properties. What the model calls compile to Same code, three languages. User.findAll({ where: { name: 'Ada' }, order: [['name','ASC']], limit: 10 }): Neo4j (Cypher) Gremlin / Neptune Dgraph (DQL) Values are always bound parameters ($p0, b0), never interpolated into the statement. The write operations, on Neo4j: Call | Cypher | --- | --- | User.create({ name: 'Ada', age: 36 }) | CREATE (n:User $props0) RETURN n | User.update({ age: 37 }, { where: { name: 'Ada' } }) | MATCH (n:User) WHERE n.name = $p0 SET n += $p1 RETURN n | User.destroy({ where: { name: 'Ada' } }) | MATCH (n:User) WHERE n.name = $p0 DETACH DELETE n | User.upsert({ … }) | MERGE | User.increment('views') | SET n.views = n.views + … | DETACH DELETE is the right default: deleting a node without detaching its relationships is an error in Neo4j, and orphan edges are never what you wanted. Associations are edges Association | Edge | --- | --- | hasMany / hasOne | outbound edge from the source node | belongsTo | inbound edge | include | a traversal — a graph walk, not a join | This is the case where a graph database earns its keep: a multi-hop traversal costs the graph engine far less than the equivalent chain of SQL joins. Indexes and constraints Node constraints (uniqueness, existence, node key) compile through compileCreateConstraint / compileDropConstraint, and compileShowLabels() lists the labels in the graph. What throws Relational-only features raise a typed GraphCapabilityError rather than producing something meaningless: That covers partitions, materialized views, row-level security, stored procedures, foreign-data wrappers and arbitrary SQL joins. Catch it the way you catch UnsupportedSchemaObjectError: Dropping to the native language For traversals the model API cannot express — variable-length paths, shortest path, PageRank — write the query yourself: queryStream() is available too, for traversals that return more than fits in memory — see Streaming. Choosing between this and a store adapter You want | Use | --- | --- | Models, associations, include, hooks, validation over a graph | these dialects | The engine's own API — Cypher builders, Gremlin bytecode, native bulk loaders | the Neo4j / Dgraph / TigerGraph stores | Relational data with occasional graph queries | a SQL dialect with recursive CTEs | Related reading Store adapters — native-API graph clients Database types — the full engine taxonomy Associations Raw queries