I had a toy project which housed all its data in Postgres and I needed a bit of graph traversal, really basic stuff. I almost prepared some ETL to load the data into neo4j/redisgraph, but then I found out about recursive CTEs in Postgres.
Granted, they won't let you do nearly as much as some advanced graph algorithms, but the ease with which you can use it in your operational data store is amazing. And with proper indexing, I could do a traversal in hundreds of milliseconds.
https://www.postgresql.org/docs/current/static/queries-with....
Neo4J has been around so long -- is anyone here using it in production and really happy with it, where it's like really crushing a use-case?
I feel like 90% of the applications in existence can go so far with a regular RDBMS that they never try out Neo4j... I know that's the case with me. Half the time I think I'd just try throwing Agensgraph[0] at the problem instead of jumping to the community version of Neo4J.
To everyone @ Neo4j, on behalf of the Graphistry team, big congrats!
This may help non-graph folks understand the community a bit. Neo4j has a bunch of cool bits, and it's been a pleasure watching them bring two specific "aha!" moments to customers. Our tech helps teams build scalable visual workflows that include visual graph, so we're often brought in near the beginning of a graph project, and have repeatedly seen two situations where a DB at Neo4j's quality shines:
1. Performance: A teams starts using their existing data stores -- SQL, Splunk, etc. They'll get quite far. Often, however, they will hit some query that just cannot perform. E.g., for two bank accounts, all paths between them. For different DBs and workloads, these can be different things.
2. Ease: Asking for something like a 360 view around a device, user, patient, account, etc. is hard in sQL - you don't know what column, table, etc. to look at. Or imagine the above shortest-paths query. Cypher makes writing this stuff EASY, so in a world where a lot of people can barely do SQL, that's a superpower.
Neo4j has been broadening by entering the scaleout world, app dev world, and adding multi-modal & ML capabilities, which are all important things and help grow the eco-system. Congrats again!
This is great news for Neo4j, and for the thousands of organisations that are just starting to realise that they have an unmet need that graph technology can solve.
What we are seeing here is the 'commodification' of graph, a trend that happens in technology in general. Companies that launched ten years ago, on a massive investment with their own proprietary graph technology - I'm talking the likes of Twitter, Facebook and so on - today the same features could be implemented with a fraction of the investment. They'll do this by leveraging Neo4j.
This funding we'll broaden the reach of graph technology, while reducing the overall cost for individual organisations to adopt. Social networks, recommendation engines, fraud detection systems are all now easily within reach. Check out our own free and open-source recommendation engine, which was built on top of Neo4j, for example: https://github.com/graphaware/neo4j-reco.
We live in exciting times. While the commodification of what we call 'graph 1.0' is in progress, what Tesla's head of A.I. Andrej Karpathy brands "Software 2.0", that is the intersection of machine learning and software development is rapidly picking up pace. We're only at the beginning of the hype cycle on this. And guess what? IT is an established fact, is that graph is playing a central role in this transformation process.
We are proud to say that our organisation is at the forefront of using graph technology to derive insight and meaning from unstructured data - we call this GraphAware Hume. We're really excited about this!
As you can see we're are pretty passionate about graph technology, and Neo4j in particular, and in our opinion we're at the beginning of what is going to be a very transformative adoption. If you're thinking about exploring how graph might fit into _your_ organisation, of course feel free to reach out.
Disclaimer: GraphAware (https://graphaware.com/) is Neo4j's solution partner
The frustrating thing with Neo4j is that they have two modes - a fairly neutered open source version, and a ~$35k/node enterprise version, with absolutely nothing inbetween. They're apparently doing a cloudy hosted enterprise version somewhere inbetween but that's some time out and not a self-hostable option.
People think Neo4J is for things like social, but Facebook's social graph doesn't actually work like Neo4J does – Facebook's load is dashboard shaped and read dominated, so query/storage/writer separation is really important. http://www.dustingetz.com/:datomic-facebook-tao/
Neo4j seems to have performance issues: https://www.arangodb.com/2018/02/nosql-performance-benchmark...
And as far as I can remember from a former project the scalability is pretty limited (but this could have changed).
I have only used Neo4j for one customer project, but I experiment with it myself (I also use RDF datastores) and have used Neo4j in examples for two books I wrote. Good technology, and I am glad they are successfully transitioning from the open source community version to also making money with their enterprise version.
It is still a research thing, but I am starting to see occasional papers on inducing relations in graphs using deep learning. If this proves useful, that should help the growth of graph databases and the use of knowledge graphs.
However, as another commenter ‘hardwarsofton’ said, just using Postgres is very often all I need.
Huge fan of Neo4j and there are many data stores that would benefit from a graph, security data being one. And Cypher is a fantastic query language for graphs and should be the standard.
Neo4j, and graph databases in general, are an excellent use case for IoT access management.
Our schema involved taking physical assets/personnel and representing them as different labels: machine, factory, production line, user, usergroup, etc. We then drew complex relationships between different user/groups in the organization and the assets they were responsible for.
At first, we used a relational database, but it soon became difficult to go more granular than simply: user belongs to usergroup, usergroup belongs to client, client has factories, factories have lines, lines have machines.
As many have pointed out here, it's not that you can't do this with non-graph databases, it just requires a more complex query layer. Neo4j allowed us to represent complex business relationships as natural language, and that really helped us as the business scaled.
Is "nabbing a Series E" really a sign of something flourishing? The way I view investment rounds is as a letter grade. Once you've reached a "Series F" maybe you've just failed? Has this company made any profit, for instance? Just conjecture.
Nice to see a Java based technology taking off.
Java will always be king of enterprise despite all the drama with the future of the JRE.
Love Neo4j. The console makes it SO freaking easy to use!
Good to see interest in this space brewing.
I used to use OrientDB but moved away due to stability issues (long ago now so hopefully they have that sorted). I also just noticed they’ve been acquired by SAP!
For me graph layouts are conceptually superior vs relational when explaining to non techie users.
Practically however I now stick to Postgres - it’s ‘good enough’ (for what I’m doing) and has a heap of benefits in and of itself.
I looked st Agensgraph but I couldn’t get enough info on it, plus it is a custom version of Postgres (not a plug-in) and i think they recently switched to AGPL which makes it overall less exciting to investigate.
I know there are places where having a real graph db helps but I’ve not personally hit those scenarios yet.
The problem with neo4j is that Cassandra is a brilliant alternative with a superb hosted story - lots of providers have hosted Cassandra which scales to petabytes levels.
And there is a huge scalable graph stack with Cassandra - Datastax Enterprise Graph, Titan,JanusGraph (where Google is involved), Tinkerpop,etc.
The production readiness of neo4j is something I'm still not quite sure about.
It truly shines as an embedded graph db though. I wonder if there is a Blockchain story around neo4j (as a replacement for leveldb) that makes this more interesting. After all there is a lot of excitement around DAG based blockchain alternatives.
Does anyone have experience with both Datomic and Neo4j? Are they comparable?
Has anyone used stuff like ontotext graphdb or stardog?
I'm also interested in peopels opinions of Neptune in that domain.
Mostly for medical reasoning on RDF OWL ontologies such as "Ontology Development and Debugging in Protégé using the OntoDebug Plugin"[1]
This is a little off topic, but there are so many graph databases out there. It's hard to know which one to start playing with..
One would think that Neo4j probably is the most stable one? But it's unclear to me if the full version is open source or not? [1][2]
Has anyone tried several?
Has anyone tried Dgraph? [3]
[1] Community is limited according to Wikipedia
[2] Trying to download enterprise takes me to a "Start a Free 30-Day Trial" page
[3] https://dgraph.io/ ?It would be great if the Neo4j team helped jepsen.io do an analysis of their enterprise clustering features.
I'm curious if any of you have tried it against another commercial graph db like AllegroGraph?
I've been using Neo in production on GrapheneDB with py2neo and Flask for about a year. Love it.
The reason I use a graph is for consistency from my product level business logic to my implementation.
Basically, to solve my problem, I started with a set of english statements, which yielded a grammar, that I described as "objects and morphisms," (things and relationships) then implemented it in a graph - put a front end on it and built a product.
Graphs provide coherence to my problem. Could an RDBMS do this? Yes, but not without a complex intermediate query layer. I think of using a graph as analogous to specifying your problem in terms of a functional language instead of imperatively. The reason to do that is because your product is the result of maintaining consistency of an abstraction, like a DSL or a game, instead of just retrieving stored values, documents and their variations.
It's disruptive to a lot of orgs as well, since there is a lot of sunk cost in RDBMS experience, so I think the applications are all net new projects. I don't foresee anyone migrating to one, but I do see a point where majority of new products use one.