You are here
The graph engineering lifecycle
Design, configure, engineer, iterate and automate graph model production: the whole lifecycle, without writing bespoke ingest code for each project.
Graph database compatibility
Every database below can be written to from the platform, and the list grows rather than narrows. That is the point. A model held outside any one vendor's tooling turns database selection from a decision you have to get right at the start into one you can test, defer, and revisit.
Written to today
These are graph database targets rather than customers of ours. Support comes from the query language, so the list is a snapshot of what people ask for and not a boundary on what is possible.
Amazon Neptune
Neo4j
Memgraph
GraphDB
Stardog
RDFox
Datagraphs
JanusGraph
Compatibility
Writers target SPARQL, openCypher and Gremlin. Anything that speaks one of the three is supported as standard, which is why this table is about languages rather than about deals. Several databases speak more than one, and those are the easiest to change your mind about later.
Query language support as published by each vendor. This list is added to continuously, so its absence from the table is not a statement about a database. If yours is missing, ask us.
Why they perform differently
To be called one, a database has to store nodes and edges and let you traverse them. That leaves a great deal of room underneath, and the room underneath is where the performance differences live.
the difference
Underneath the traversal, one product may be a native triple store, another a document store with graph semantics on top, another a key-value store using adjacency as keys, another something close to a relational engine. Each of those makes some access patterns cheap and others expensive. Which shape suits you depends on your model and on the questions you expect to ask of it, which is information nobody has at the point most teams are asked to choose.
The consequence: the honest answer to “which graph database is fastest” is that it depends on your model, and you can find out in an afternoon instead of arguing about it for a quarter.
storage models five broad kinds
RDF store native triples
Document a record per entity
Key-value adjacency as keys
Wide column rows and families
DBMS only no store of its own
each makes some traversals cheap and others expensive
Common paths to the wrong database
Every one of these is a reasonable decision made with the information available at the time. That is what makes them worth naming.
Every vendor can show complex traversals at remarkable speed, and each of them is telling the truth about some workload. Whether it is the truth about yours is a different question, and one only your model can answer.
instead run your own model
Modelling inside a database's own tooling is the fastest way to start and the most expensive way to leave. The model becomes an artefact of that product, and moving means rebuilding rather than reconfiguring.
instead hold the model outside
Picking the database as step one quietly biases everything after it. You shape the model around what that product makes easy, and by the time anyone asks whether it was the right fit, the model can no longer answer.
instead model first, then pick
The team knows Cypher, so the SPARQL options never get looked at. It is a sensible constraint, but if the tooling makes the query language a configuration detail rather than a hiring decision, it is a constraint you do not have to accept.
instead let the model decide
Organisations frequently run different graph databases for different applications, one tuned for an application and another for analytics. It rarely gets discussed, because with bespoke pipelines it means building everything twice.
instead two Writers, one model
How to actually compare two
This is the part that used to be unaffordable. Loading a real model into a second database meant writing a second pipeline, so almost nobody did it, and the decision got made on reading instead.
the test
Build the model once in Studio and run the transformation once. Then point two Writers at the output, one per candidate, and you have the same graph in both, ready to query the way your application will. If the open question is the formalism rather than the vendor, rework the model as a property graph as well and run all four, since the model is configuration rather than code either way.
The consequence: you get to answer “which is faster for us” with a measurement instead of an opinion, and you get to answer it before you sign anything.
No, and this is a common starting point. The way out is to lift the model out of the vendor's tooling and rebuild it in the platform, at which point the source translation, the transformation, the modelling and the loading are all in one pipeline you control. From there the current database is simply the one you happen to be writing to.
It is a real decision and it is not the same decision as picking a vendor, though the two get run together constantly. RDF brings a standard vocabulary, formal semantics and portability. Property graphs are often more direct for application workloads. You can model the same domain both ways here and run them side by side, which is the only way we know to answer it honestly.
It is a reasonable first step, particularly for a proof of concept, since the procurement and the operational knowledge are already there. Treat it as a starting point rather than a conclusion, and test it against an alternative before it becomes production.
If it speaks SPARQL, openCypher or Gremlin, yes, as standard. The table above lists the ones that come up most often, not the ones that are possible. Where a database is missing it usually means nobody has asked yet.
Documentation quality, support and SLA, hosting model, client library coverage, scaling options, licence type, track record, and how it handles indexes, partitioning and replication. Most of these are easier to judge than performance, which is exactly why performance is the one worth testing rather than reading about.
No. A transformation produces RDF or node and edge CSV whether or not anything loads it, so the modelling work can start and finish before a database is chosen. Plenty of teams use that period to run the selection properly. If the source is relational, you can go further and query the model without loading anything at all, with SPARQL translated to SQL against your tables as it is asked. It is bound by your relational database's own performance and it leaves no graph behind, so it is a way to try a model rather than a way to avoid the decision, but it does mean the decision can wait.
We will model the domain, transform a sample of your data and load it into the databases you are considering, so the comparison you make is your own.