Is there a graph database which allows for arbitrary edge types to be added without requiring a wholesale migration?

Question

Here's the use case: say I wanted to build a notes app that allows users to cross-link between notes, or parts of notes. When the user creates a cross link (edge), they can specify the type of link (edge type). The user can also enter a custom link (edge) type.

For example, a user writes one note about Celia and another about Barry. She then links the Barry note from Celia, with a link type "HUSBAND". She links the Celia note from Barry, with a link type "WIFE". Neither "WIFE" nor "HUSBAND" were explicit edge types in the pre-existing schema of the graph database.

In most graph databases I've looked at (e.g. Neo4j, ArangoDB, Amazon Neptune) adding a new 'type' of edge (link) between nodes requires a wholesale migration of the database, since edges are typically stored as collections in those systems.

Rather than allowing the user to define new collections on the fly, are there any graph databases which treat edges differently, i.e. don't require me to define all possible edge types up front?

Answer 1

What you are describing here sounds similar to how you might think about modelling a hypergraph. If it is important to have, using your example of HUSBAND and WIFE declared before Barry and Celia, then you may well consider modelling HUSBAND and WIFE as nodes in their own right, and then when data of Barry and Celia are entered into the database, you would attach them to those nodes. How you might model this will vary, but an example (of many) may be (Wife)<-[:HAS_REL_TYPE]-(Celia)-[:KNOWS]->(Barry)-[:HAS_REL_TYPE]->(Husband)

Answer 2

Disclaimer, I'm the golang typeDB maintainer.

The previous answer is correct, your use case requires modelling a hypergraph with implicit inverse relationships and N-ary relations. To my knowledge, TypeDB allows you to do just that.

https://vaticle.com/typedb

To your specific questions about avoiding migration, as far as I understand TypeDB, you don't need to migrate anything if:

• Your new relationship can be expressed as a rule. For example: If city in country and country in continent, then city in continent. TypeDB applies these rules during query time which means you can query for all cities in Asia and you get q correct list. Furthermore, TypeDB supports Type Hierarchies i.e. Capital is subtype city so you can than combine both i.e. query for all capitals in Europe and you get a correct response. It's quite impressive what can be expressed with rules and rules can freely added after the schema.

• Your schema update is additive only i.e. you model marriage, divorce, both with location, and at some point later you want to add honeymoon and link it to location. You can do that for the entity honeymoon, but have to update existing data after the schema change. Again rules are your friends that means instead of writing relations, you make rules.

Obviously, non additive changes i.e changing entities, deleting attributes, or changing existing relations requires some form of data modification or migration.

If you prefer a more traditional schemaless noSQL DB, then Arrango gets you the hypergraph plus open schema, but does not allow sub typing and rules. Instead, you have to formulate all rules as explicit relations.

Personally, if performance and especially performance at scale is of highest priority, Arrango is impossible to beat. If you need even bigger ultra extreme planet scale, then only infinite graph can do the job.

Conversely, if functionality and especially complex domain requirements are paramount and performance only needs to be okay, then nothing beats TypeDB. In fact, half of the big pharma companies using TypeDB to model complex biological data required for drug discovery. TypeDB enables a multi billion industry, and, to my knowledge, very few graph databases actually can do what typeDB does with ease in terms of reducing complexity while increasing expressiveness.