> By 2025, graph technologies will be used in 80% of data and analytics innovations, up from 10% in 2021, facilitating rapid decision making across the enterprise.”<p>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?)
I've done development on an app with Neo as the back end, and what I liked about it was mainly py2neo and the cypher query language. Even after developing in it, approaching another graph in DGraph was conceptually impenetrable, as my impression of dgraph was they had a bunch of unnecessary and poor abstractions in their documentation. The next candidate is the redis graph, but I haven't. With Neo, if you learn cypher, you literally don't need to know anything else about it to be useful in it, which brings me to what I think their real market is.<p>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.<p>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.<p>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.
What this tells me is that the graph db space has a lot of room in it for someone to come along and make a kick ass product, because honestly every time I've had a problem a graph db can solve I remember I basically only have a few mediocre choices to choose from.<p>Neo4J has been very meh in my experience, but they are the biggest.
I've been looking at Bitnine AgensGraph and thus also Apache AGE. These are (related) extensions of PostgreSQL that use PostgreSQL to implement a complete graph database and Cypher query language. Interestingly you can even mix SQL and Cypher in the same statement.<p>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.
cypher is really cool and with neosemantics[1] you have the best of both worlds - labeled property graphs and rdf* they even have a cool reasoner and sparql.<p>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.<p>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.<p>1: <a href="https://github.com/neo4j-labs/neosemantics" rel="nofollow">https://github.com/neo4j-labs/neosemantics</a><p>2: <a href="https://github.com/structr/structr" rel="nofollow">https://github.com/structr/structr</a>
I always find it amusing how much graphQL there is without actual graph db behind it.<p>Seems the concept of having fluid relationships is appealing for querying but not structuring/storing... which seems like a disconnect.<p>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.<p>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.
Series F isn’t an inherently bad thing. That just means that they’ve been around for awhile, want funding to accelerate growth, and don’t want to go public. Every company doesn’t have to grow super fast after 1-2 massive funding rounds and then get acquired.
The Enterprise version is ridiculously expensive. Think Oracle/IBM type of pricing.<p>Community Edition is hobbled to the point where I wouldn't recommend anyone run it in production.
I worked on a use case which was clearly in graph in nature. So graph database seemed a natural choice, of course Neo4j was one of the most heard product even back then.<p>We did evaluate Neo4j, but put down due to its complex query language (cypher) and slowness. It was really an awkward language, super awkward.<p>We also evaluated arangodb and we found it much better than Neo4j. Performance was good and its query language was better too.<p>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.<p>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.
I joined a small open source project that had decided to use Neo4J instead of a SQL database as its primary store. Simple queries mysteriously caused Neo4J to gobble up huge amounts of memory. Neo4J struggled even though we had fewer than a million items, sometimes getting so stuck that we had to restart the database. There wasn't any good tooling to explain why our queries were so slow. We'd already upgraded our VM beyond what we originally hoped to spend and were reluctant to spend even more on a larger one.<p>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.<p>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.<p>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.
Graph DBs work if you know your relationships of interest ahead of time, and are happy to have them baked into your dataset.<p>With relational databases, you can join on anything anywhen, so you can explore new relationships as you go.
Curious what something like Neo4j offers over a something like [this](<a href="https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-overview?view=sql-server-ver15" rel="nofollow">https://docs.microsoft.com/en-us/sql/relational-databases/gr...</a>) in MSSQL.
> Series F<p>Yikes<p>> largest investment in a private database company<p>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?
Neo4j can be a useful supplement to apps that have data models that include graphs.<p>If you are using relational db you can use recursion to achieve the same effect without having bring n4j and cipher into your stack.<p>A simple example of implementing a hierarchical graph data structure on postgres and exposing it via graphql can be found on the hasura blog.<p><a href="https://hasura.io/blog/authorization-rules-for-multi-tenant-system-google-cloud/" rel="nofollow">https://hasura.io/blog/authorization-rules-for-multi-tenant-...</a>
It's always interesting to hear about huge funding rounds for companies I've never heard of. Even more so when they apparently work with a bunch of companies I have heard of.