Amazon Neptune – Fast, reliable graph database built for the cloud

No lock in at all.

1) "native" graph db Neo4J is an example of this. This takes advantage of index-free adjacency. Each node knows what other nodes it is connected to and hence traversals are very fast. The issues you run into are when you try to scale. Data that fits onto a single machine is fine and you can replicate your data for fast parallel reads/traversals across disparate regions of a massive graph. However you no longer have the concept of data sharding and distributing the graph as index-free adjacencies don't translate across physical machines. And another drawback is highly connected vertices, you will expend a tremendous amount of resources deleting or mutating a vertex with, say, 10^6 edges. But that vertex is probably a bot so you should delete him anyway.

2) inverted index graphs, non-native graphs, whatever anti-marketing name it might have. These rely on tables of vertices and other tables of edges. Indexes make them fast, not as fast for reads but very fast for writes. And you get distributed databases (Cassandra, for example, a powerful workhorse of a backend with data sharding and replication factor, etc.). But then you have to yet another index to maintain and the overhead can get expensive. This is the model adopted by DataStax, who bought Titan DB (hence the public fork to Janus) and integrated it with some optimisations and enterprise tools (monitoring etc, solr search engine) to sit on top of Cassandra.

Both now have improved integration with things like Spark. Cypher is probably faster than Tinkerpop Gremlin especially with the bolt serialisation introduced in recent versions of neo4j.

So janus is the graph abstraction layer of the second type and so needs somewhere to save these relationships. It all comes down to use case (and marketing) to decide what works best for you.

Graph database projects are often times just an adapter for doing Graph queries on-top of another store.

At their core, a graph database can be reflected simply with just documents and adjacency lists https://en.wikipedia.org/wiki/Adjacency_list

It provides tools to run complex queries on graphs, and manages data models and indices to execute them fast.

However, when we get to manage the storage layer (Bolt, Level -- that's being generalized into local-KVs in the next release) we get to build our own indexes for better data management and performance. But there's no reason we can't hand that job off either -- hence supporting multiple (remote) backends. For the local stuff, though, at some point, Bolt is just a very good BTree implementation.

Even propagation and node invalidation are awesome for rapid what-if style experimentation, and I am so psyched to see more and more attention being paid to graph computing in general.

[1] https://www.github.com/kchoudhu/openarc [2] https://www.anserinae.net/whats-cooking-openarc-edition.html...

Is it fair to say that traditional RDBMS/SQL are for storing different "sets" of related information (tables for products, users, orders).

Graph databases are for storing data about the _same_ set of data as it interrelates to itself.

- a User and and all their Friends (who are also users) - a Keyword and all associated Terms (which are also keywords)

Is that right?

Seems like a management interface is a clear cut derivative product. Where’s the source code?

Or perhaps amazon does consider licensing and only builds on top of, eg Apache licensed projects?

the question in amazons case is that since they sell the infrastructure, they can and probably do undercut any competing providers by charging themselves less.

so, it seems monopolistic. otoh their service is good and their customers get at least reasonable prices. so ... ?

To be clear, it’s not the hosting of open source applications I see as the problem, but the closed source management/orchestration software built on top of it.

SPARQL is supported.