by hugofirth on 6/17/21, 4:29 PM with 133 comments
by softwaredoug on 6/17/21, 6:13 PM
What is behind the thought that graph databases are going to grow so much in the next few years? To me they've always had a niche use... Are they really going to be ubiquitous (like this funding seems to assume?)
by motohagiography on 6/17/21, 8:47 PM
The opportunity I understood after using Neo was the big product play would be a kind of mental shift for enterprise data analyst users whose jobs exist in excel/powerbi today with power users using Cognos, and less devops/SaaS company/etc. I over-use Apple as an example, but if Apple entered into enterprise data products, Neo would be the kind of thing to be the underlying tech for it, as if you are an apple user, an apple'ey analytics tool would be based on users producing and reasoning about their data with graphs instead of tables, if you could imagine a kind of photoshop for data, or a fundamental conceptual change from spreadsheets to graphs. They aren't as competitive as a data tool, but I think they are unrivaled as a knowledge tool.
The tech is really great, but the product piece appears to have been a challenge because the use cases for graphs have been very enterprise'y, which has limited adoption because people who operate at that higher business logic level of abstraction that graphs enable are not the people picking and adopting new technologies. The growth will come from younger people who learned python in high school, and have a more data centric world view. Maybe that's the play.
Anyway, as a user I can see why they got participation on an F round. Imo, they've solved the what/how/why and have done some amazing science and engineering, and what I hope that money buys them is some magic.
by Grimm1 on 6/17/21, 5:35 PM
Neo4J has been very meh in my experience, but they are the biggest.
by topspin on 6/17/21, 9:28 PM
This approach of extending PostgreSQL is very appealing to me. There is a great deal of value in the PostgreSQL stack that doesn't need to be reinvented just to deliver a graph database and query language. How much easier is it to adopt graph database techniques when it is simply an extension of database technology nearly everyone is already running? Conceivably one might find some future version of PostgreSQL RDS (and other cloud PostgreSQL services) delivers Cypher.
by nisa on 6/17/21, 5:32 PM
that being said I thought about porting it to postgresql with apache age vs. using neo4j for a project because it's faster at least for this usecase. Easier said than done, through.
If you want to play with graphs and linked-data it's super cool. There is also structr[2] that builds CMIS / Alfresco ECM like functionality atop neo4j with graaljs scripts.
by tgtweak on 6/17/21, 5:51 PM
Seems the concept of having fluid relationships is appealing for querying but not structuring/storing... which seems like a disconnect.
I have only seen a few Neo4J systems in serious production workloads and they were ALL on logistics... I'm not sure that it's being positioned (or interpreted) as a nice simple solution to start out on.
Edit: I just checked out neo4j "bloom", and it's definitely a good way to make graph more accessible - they should continue to build further on it.
by jrsj on 6/17/21, 5:55 PM
by busterarm on 6/17/21, 6:26 PM
Community Edition is hobbled to the point where I wouldn't recommend anyone run it in production.
by heldsteel7 on 6/18/21, 6:37 AM
We did evaluate Neo4j, but put down due to its complex query language (cypher) and slowness. It was really an awkward language, super awkward.
We also evaluated arangodb and we found it much better than Neo4j. Performance was good and its query language was better too.
What we realised in the process is, using graph databases is more of a cultural transformation as well. SQL is much well understood, well adopted and well supported by community.
Ultimately we implemented the use case in Postgres, and thank God we did it that way. IMO, we can still get all the benefits of graphs we SQL databases with little efforts.
by zestyping on 6/19/21, 7:45 PM
We had a team member who had used Neo4J professionally for years and could not figure it out. And we only had one; every other teammate and new volunteer had to be trained in a strange new way of thinking about databases and a new query syntax. Setting it up to run locally for development was a difficult process. Progress was slow and our code to access the database was messy. We kept being promised that, in exchange for these heavy burdens, Neo4J would do amazing things for us once we started doing graph queries, but we never got there because it couldn't do the basics.
We rewrote the project to run on PostgreSQL. Five tables, properly indexed, lightning fast, easy to set up and understandable by anyone. A hundred million rows and it didn't break a sweat, on the lowest tier of machine. Even graph queries were straightforward and quick.
Advice: Don't use Neo4J as your primary store, and avoid it altogether if you want volunteer or casual contributors. For us, it was all costs and no benefits.
by haolez on 6/17/21, 5:29 PM
by nrjames on 6/17/21, 8:47 PM
by cryptos on 6/18/21, 1:36 PM
by somewhereoutth on 6/17/21, 6:22 PM
With relational databases, you can join on anything anywhen, so you can explore new relationships as you go.
by __jem on 6/17/21, 8:04 PM
by whalesalad on 6/17/21, 5:29 PM
Yikes
> largest investment in a private database company
I guess this is one of those PR moves that is trying to make something lame sound good? If your customer portfolio includes Walmart, Volvo and AstraZeneca why are you raising money a 6th time?
by xibalba on 6/17/21, 7:25 PM
by diveanon on 6/18/21, 10:32 AM
If you are using relational db you can use recursion to achieve the same effect without having bring n4j and cipher into your stack.
A simple example of implementing a hierarchical graph data structure on postgres and exposing it via graphql can be found on the hasura blog.
https://hasura.io/blog/authorization-rules-for-multi-tenant-...
by mkr-hn on 6/17/21, 5:21 PM