In gremlin and this new nGQL, the whole notion of "INSERT," implies that the graph is just a representation over top of a relational db, and power users should understand RDBMS concepts articulated in SQL queries first with this novel and cute graph thingy after for managers. It's like asking Excel users to understand and care about pointer arithmetic.
Gremlin leverages some peoples mental sunk costs in SQL, where cypher is very verbose, but lets me reason purely about my graph model without hacking over the implementation. The others aren't bad, but the people who will be using graphs won't be DBAs.
In this sense, cypher/Neo4j isn't a competitor to noSQL and rdbms products, it's a competitor to spreadsheets, where the majority of people actually get work done themselves, instead of specifying it and having others engineer it.
But then I realized that sharding and localizing data can accomplish roughly the same thing.
Also the graph database doesn’t have to duplicate data so much for joins, saving on memory.
If you are going to have a huge dataset, build your data as RDMBS first and then make a cache in a graph database.
I say this only because graph databases are not mainstream yet.
Cypher was really nice, though.
It was a valuable learning experience but I find myself moving back toward SQLy and JSONy things for production models.
Transactions in N4j couldn't handle modifying one entity [edit:the schema of one entity type, I mean] while updating another, which was pretty limiting (say, you want to do safe Rails-migrations-style version bumps in the DB in the same transaction as your modifications, so they can't get out of sync). Constraints capabilities and data types were very limited. Perf if you stepped off the Golden Path, which was easy to do by accident with something that looked boring and normal, was mediocre at best for our use case (smallish sparse sub-graph fetching, mostly)
[EDIT] meanwhile, all the official material from N4J was doing its MongoDBest to sell itself as 100% suitable for production for 100% of use cases, because of course it was. Look anywhere else and you got a very different, more accurate story.
I don't know much about it but they are associated with Seshat Global History Databank http://seshatdatabank.info/ which, if I understand correctly, is something like a serious attempt at "psychohistory" (like in Asimov's Foundation.) https://medium.com/terminusdb/stuffing-the-whole-human-histo...
(I wish Terminus didn't publish articles on Medium, where you need an account to read)
For application developers, having access to general public Knowledge Graphs like DBPedia and WikiData can be a very good resource.
While I am also a big fan of more general graph databases like Neo4J, not even mentioning SPARQL is such a HUGE OMISSION that I have to suspect some commercially motivated bias in this article.
The decision of which graph data platform to use is not always black and white. Use SPARQL with a RDF/OWL data store or a more general graph data store like Neo4J as appropriate. Learn both technologies.
'GQL is an upcoming International Standard language for property graph querying that is currently being created.
The idea of a standalone graph query language to complement SQL was raised by ISO SC32/ WG3 members in early 2017, and is echoed in the GQL manifesto of May 2018.
GQL supporters aim to develop a rock-solid next-generation declarative graph query language that builds on the foundations of SQL and integrates proven ideas from the existing openCypher, PGQL, GSQL, and G-CORE
languages. The proposed SQL:2020 Property Graph Query Extensions already build on these existing languages.'
Though I could see why someone wouldn't like SPARQL and RDF, with its bulk reuse of other W3C and TBL concepts such as URLs, resulting in atom and predicate names verbosely and pointlessly beginning with "http://".
But there are many performant SPARQL-enabled databases (back when I wrote my Master's in 2014, that even included Oracle), and they are indeed quite performant - though there are details like batch/realtime materialization and the like.
In my experience, AllegroGraph was pretty fast enough (apparently someone even uses it now to translate between HL7 schemas of multiple providers in USA)
Once it use vectors/maps to describe the query, you can compose/generate/transform with simple data operations (concat, filter, assoc...)
It’s useful you’re comparing these languages. I would suggest to make yours more like Cypher, specifically the arrows <--> are much less verbose than BIDIRECT/ REVERSELY, and MATCH is a lot less verbose and more powerful than other query languages. It sucks to want to use Neo4j then not be able to due to license and business issues.
If there were a quality graph db with a permissive license and Cypher, serverless hosting, search and JSON, we’d use it... neo4j didn’t work out because they require an NDA to get a price quote (!) and the Redis Source Available License basically reads, “you can’t use this for startups”; RedisLabs.com quotes a “low” price of $500 monthly to get modules with basic stuff like JSON, Search, and Graphs (“cloud pro”) - but then the pricing page triples that number. We pointed this out to redislabs at least 3 different channels (email, git, Twitter) but the pricing error still exists on their cloud page. If RedisLabs leaves an $800 / mo typo sitting on their page for months, how do you trust them with sensitive customer data? Went with Amazon Aurora PostgreSQL instead. Love Row Level Security (but wish you could specify columns inside your row policies)
You might also include ArangoDB AQL
RedisGraph is licensed under their weird license but as far as I can tell you just can't expose the RedisGraph API directly to your customers. Building an API on top of it that adds some abstractions should be fine (think a social network powered by the extension). I could be wrong about that though.
Are you actually doing graph work in Postgres? I learned about recursive CTE queries once upon a time and that was what prompted adoption of Neo4j.
(I'm not a lawyer and don't take legal advice from the internet)
and might find some of these blog posts helpful https://blog.igovsol.com/
Overuse of WITH does make it a bit more imperative, but also makes it easy to shape the result in the form you want it in. Cypher has been a joy to work with. Gremlin, by comparison, does not attract me at all.
Context: In web app usage scenario the tooling available for GraphQL seems more popular (with react libraries) than Cypher.
Cypher is a graph query language.
GraphQL is an API query language to query tree like structures (trees...), nothing to do with graphs actually.
Other than that though, you are quite correct, the two do not serve the same purpose.
Neo4j has an extension that exposes a GraphQL API that converts the queries to Cypher (https://neo4j.com/developer/graphql/#neo4j-graphql-java). I've used it for some basic things but for anything complex you need to be careful and inspect the queries it produces.
Also just because you cannot query at arbitrary depths doesn't mean that GraphQL doesn't work with graphs, just that it might be a poor choice of tool for that work.
So it doesn't need to be bad necessarily, if code follows the same conventions.
Related, do any of the let you do something simple like return a count of vertices obtained from a traversal, or do you need to walk a result and count them yourself?
Also, much of the work in validation (SHACL, Shex) of graphs leverages SPARQL so it's not going anwhere soon. I would like to see it evolve to allow more vertex based searches without the need for extensions though.
I think spreading those kind of lies if a part of why there is a divide between the W3C (at least the RDF community) and the rest of the word. The W3C should be more transparent about RDF capabilities and realistic about the real power of the Semantic Web.
 this false because RDF use IRIs not URLs, and not all IRIs are dereferenceable. Moreover, even URLs used as resource id are not constrained to be dereferenceable per the spec (and when they are, you'll get a lot 404 in practice). Also, the same effect can be obtained as easily with properties (key value pair) attached on nodes of graph database.
That has been one of the main motivations why I've been working on a content-addressed semantic data/ontology format with a modern decentrelized stack in mind.
Thus, if someone is looking to unify graph QLs that are in actual use in "business" problems, SPARQL and the overall RDF aren't going to get attention. You can start with the fact that RDF basically assumes you want to globally address all your data with URIs, which will result in ridiculously verbose overhead in naming/addressing. Nevermind the fact that such things basically promise some sort of long term durability that the actual web has shown doesn't exist. After all, today's URI link to URI www.tla.com/link/to/some/data can mean the world wide wrestling foundation one day, and the world wildlife foundation the next.
In particular, Gremlin was adopted by DSE / Titan / successor to Titan which ran atop Cassandra for near-limitless scalability.
RDF and the Semantic web, while being intended for the massive WWW, seemed to not have any care for demonstrating techniques, queries, and architectures at scale.
Likewise, are Datalog and Prolog used extensively?
URIs and RDF in general don't need to use public HTTP links or anything like that, meanwhile the layered systems like OWL and RDFS provide some impressive features for implementing complex systems, especially when you actually want to use a semantic graph instead of loosely-schemed bag of nodes and vertices common in non-RDF graph databases.
It's just not getting the "kool" looks and gushing reviews, mostly written by people who totally missed all the previous research. Which is a common problem all around in computing.
As I mentioned in another comment, the SPARQL endpoints for WikiData and DBPedia are fantastic resources, for some projects.