[handrous]

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.

[dgb23]

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 can’t wrap my head around however is temporal data modeling with graphs. Haven’t seen or thought of anything too satisfying yet, that meshes well with how I think about graphs. Whereas in SQL it is more explored and clear to me.

I agree that their marketing is very aggressive, but this tech has quite some merit.

[LukeEF]

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

[chippiewill]

I used to work for a database vendor. I'm getting serious 'nam style flashbacks reading your comment.

The capability of sales to sell a product to massive companies for a use case that we're actually not very good at was unbelievable.

[handrous]

It keeps working, so I can't hardly blame companies for doing it. The people who are falling for it, on the other hand....

[cerved]

I used to work in IT sales and I'm not surprised

[oauea]

I'm sure it's fast, but also consumes a ridiculous amount of memory. Tried loading a smallish dataset into neo4j that runs on a 100mb ram postgres server just fine. Neo4j wanted gigabytes of memory.

[handrous]

When I used it, it was fast at a very specific set of graph traversal operations. It was extremely easy to step outside those narrow patterns, while doing things that seemed like they should be fine and were very common sorts of things one might want to do with the DB, at which point performance would become terrible. A look at the underlying data structures they use was revealing re: why they were so fast at some things, and so slow at others. And they only achieved that much performance by, as you note, eating memory like it's free (I mean, it is Java...).

It was also alarmingly weak on data-integrity protection features, like constraints, locking, and data-types, at the time. IDK, maybe they've fixed that. Then, it was IMO wholly unsuited to hosting any data set that you couldn't stand to have completely destroyed every so often (so, a very particular kind of caching, which IIRC is exactly what one of their marketing department's favorite names to trot out, Ebay, used it for then).

[EDIT] I would, however, agree with nisa's post elsewhere in the thread, that the Cypher query language is excellent.

[nisa]

only looked through papers but this didn't look good for them (but maybe an older version - paper is from 2015): https://static.googleusercontent.com/media/research.google.c... - that's why apache age is really interesting or will be maybe one day.

[detaro]

Did you do anything to configure that? If I remember correctly (has been a few years), Neo4j will be default reserve a bunch of space for caches and such (on top of default reserved heap sizes etc for Java). As such, the defaults don't necessarily say much.

[economusty]

Gotta love the jvm.

[objektif]

So are you saying sales works?

[handrous]

Yeah, I mean, it's not the first time a database that's best-suited to a niche use-case has successfully had its market hugely expanded by sales & marketing promoting it as a superior replacement for what are in fact better general-use products. Clearly, it's a playbook that works.