Live data from Hacker News

Neo4j raises $325M series F

neo4j.com

71–80 of 135 posts

Re: Neo4j raises $325M series F

#71
post #12

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. Neo4J has been very meh in my experience, but they are the biggest.

I investigated using Neo4j back in 2010 for storing the schedules/routes of ocean shipping freight companies, forwarders, etc. The first cut of the system stored the schedule data in a graph like way in MySQL, but to do recursive SQL queries (needed for the types of queries being performed) was annoying. Things worked well enough, but a graph database would have resulted in a much more logical representation of the data structures being used - and the code behind the queries easier to develop.

That said, the 2nd system never got off the ground, I quit the badly run startup before finishing it. And now that I have a bit more experience with Neo4j, I'd say it would have been a bear to fully implement. Java is too heavy and Neo4j is a memory pig. It works, I can't say it is bad or perhaps iffy like Tinkerpop, but it is "Enterprise Software" and everything that is associated with that meme.

I have been using Tigergraph for my latest research into modeling the schedules etc of rail transport. It is much faster than Neo4j, requires far less memory (I can store every bit of data I need to in it unlike with Neo4 (would need multiple 64GB of RAM servers)), and its programming language is pretty nice once you get the hang of it.

So I'd recommend Tigergraph. The downside is that it is not as 'plug and play' as Neo4j, does not has all the mindshare/fancy bells and whistles, and is entirely C++/Unix based. So having some UNIX sysadmin experience is helpful unless you want to use their cloud solution.

Re: Neo4j raises $325M series F

#72
post #59

Earlier quoted context omitted.

> My new tech lead is talking about switching from MongoDB to one of those. File under, "not sure if a very good joke, or serious". I'm leaning toward the former. "New tech lead" is the give-away (or is it?).

So... what is wrong with them? I've only had very good experience with ArangoDB.

It's not about the databases, it's about the migration in the first place.

If you have a problem that can be solved best with a graph database, then there is no problem. Many problem can be better solved with a graph structure. Choose one, and you'll be happy.

But, if your use-case is migrating from MongoDB to a graph database, that's a bit of a red-flag. What data model do you have where you can migrate from a document/schema-less system to a graph database? Maybe the tech lead figured out that a graph model works better for your data. If that's the case, then great -- migrate away.

But given that they want to go from Mongo to a graph DB, the fear is that this is someone who is only chasing the next cool technology and not solving an underlying business problem.

Re: Neo4j raises $325M series F

#73
post #33
post #12

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. Neo4J has been very meh in my experience, but they are the biggest.

Have you checked out RedisGraph extension for Redis?

Yes. The performance is an order of magnitude better than Neo4J, but it lacks feature parity.

Re: Neo4j raises $325M series F

#74
post #21
post #3

Earlier quoted context omitted.

They're a fairly major graph database product with a well-funded sales team that has been hammering the "I mean, doesn't everything look kinda like a graph? Isn't your data kinda a graph? You should definitely use us as your database-of-record, or for literally anything else you might use a database for, look how fast we are at graph stuff!" line hard and (apparently) with great success.

I’ve used it in production roughly 5+ years ago. Both graph data modeling and cypher queries are very fun to work with. It’s both dynamic and powerful but still gives you a decent amount of structure and ACID guarantees. One thing that is much easier to model and query, or rather more natural and simple, is authorization and other granular questions you might have about how users and data is connected. A thing that I…

check OpenCrux and TerminusDB - both time traveling graphs which specialize in temporal data modelling

Re: Neo4j raises $325M series F

#75

Earlier quoted context omitted.

GraphQL has been such a bad name to deal with. I've seen so much "we need a graph, so isn't graphQL a good idea?" or "this is a graph database, so doing graphQL on it will be way easier & more natural than on a SQL db, right?". Even from technical and semi-technical people.

This always annoyed me more than it should. It's also torturing the definition of "query language." There is no equivalent of "join", or any other typical query feature such as aggregation, grouping, sorting, filtering. GraphQL has as much to do with graphs or query languages as my smart TV has to do with intelligence. It's RPC, but RPC fell out of fashion when SOAP/WSDL/XML died.

Eh, many REST endpoints are de-facto indistinguishable from RPC. Though as far as a general query language for Web clients, you can use SPARQL which interoperates well with REST principles.

Re: Neo4j raises $325M series F

#76
post #12

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. Neo4J has been very meh in my experience, but they are the biggest.

I investigated using Neo4j back in 2010 for storing the schedules/routes of ocean shipping freight companies, forwarders, etc. The first cut of the system stored the schedule data in a graph like way in MySQL, but to do recursive SQL queries (needed for the types of queries being performed) was annoying. Things worked well enough, but a graph database would have resulted in a much more logical representation of the d…

> to do recursive SQL queries (needed for the types of queries being performed) was annoying. Things worked well enough, but a graph database would have resulted in a much more logical representation of the data structures being used

I think there's plenty of room to disagree with this view that modeling graph data in SQL is not "logical enough". Though to be fair, there seems to be some ongoing work on adding some "property"-based layer to bare SQL in order to make common graphs-and-properties oriented queries a bit more ergonomic.

Re: Neo4j raises $325M series F

#77
post #28
post #22

Earlier quoted context omitted.

Honestly I never heard of it, I had a few in mind but that wasn't one. I'll give it a try next time I need a graph db maybe it can scratch my itch so to speak. My concerns basically range around memory consumption, query language and language ecosystem. Edit: Oh and I guess around like functional extensibility. The last time I used a graph DB I had to export from the db itself to HDFS and use Spark to do things like…

That's what you can do in Neo pretty easily. The DS library offers a bunch (50+) algorithms to run on the graph data directly or projected, e.g. PR on 117M wikipedia links runs in 20s.

I've had bad experience with Neo4J's memory consumption so I'm wary of that to be honest. I don't disagree that it has those things but we actively chose to go against it because of past issues with resource usage.

Re: Neo4j raises $325M series F

#78
post #36
post #12

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. Neo4J has been very meh in my experience, but they are the biggest.

Do you have any opinions on ArangoDB or Dgraph? My new tech lead is talking about switching from MongoDB to one of those.

The most recent graph DB I've used was Dgraph, I've found the interface to be good to work with and it does scale well performance wise. Memory consumption was still too high for my tastes and if you need to build common algos on top like PageRank, again for example, they don't support that out of the box. If you read through their forum you'll see they may never choose to support things like that natively so you have to do things like I did which was export the data out. This was maybe 7 months ago now.

I'll also say that working on the entire graph if you need to is difficult, they're not oriented around working on the whole more like fragments that you've paired down through your query modifiers so if you know you're going to be doing a lot of work that requires you to do things on the entire graph that may change the performance characteristics for you a lot.

I like it and would use it again but there are rough edges to work around still and it is young so know your use case and know the trade offs you're making.

Re: Neo4j raises $325M series F

#79

> 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.” 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?)

Historically, graph databases did a passable job of supporting data models and queries that were not really possible in SQL (absent proprietary, vendor-specific extensions). That's all over now, because recent versions of SQL support recursive queries that can handle general graphs quite easily. No real need for a specialized solution, even plain vanilla Postgres is good to go.

Sql syntax for such queries is super awkward with tones of gottyas, not sure how performance compares

Re: Neo4j raises $325M series F

#80

Earlier quoted context omitted.

Historically, graph databases did a passable job of supporting data models and queries that were not really possible in SQL (absent proprietary, vendor-specific extensions). That's all over now, because recent versions of SQL support recursive queries that can handle general graphs quite easily. No real need for a specialized solution, even plain vanilla Postgres is good to go.

Sql syntax for such queries is super awkward with tones of gottyas, not sure how performance compares

Yeah, but it's free and open source.
Post reply on HN