Neo4j raises $325M series F • Hacker News Board

Re: Neo4j raises $325M series F

#131

Post by AndrewBowman » Fri, Jun 18, 2021, 2:12 PM UTC

somewhereoutth wrote: post #66

speaktorob wrote: post #54

Earlier quoted context omitted.

That's exactly the trade off, isn't it? Either you do the work to store the relationships and save on the compute and memory cost later, or you pay as you go to build it in real time with a relational database. It's horses for courses.

It could be argued that a graph dB is just a really badly implemented index.

To propose a different perspective, a relationship in a graph db is like a materialized join. You pay on relationship creation (you might be using index lookups to find the nodes to connect, similar to a relational db), then for traversal it's just pointer hopping across the relationships to the connected nodes. Aside from the initial lookup of starting node(s), traversing the graph won't use indexes at all, so becomes constant time operations.

Re: Neo4j raises $325M series F

#132

Post by thu2111 » Fri, Jun 18, 2021, 2:21 PM UTC

fedder wrote: post #126

Barrin92 wrote: post #97

Earlier quoted context omitted.

and the sheer size of these rounds always astonishes me for very specialized software products. 300 million bucks, that's enough to build a death star, what do they do with all of the cash

apparently building a new HQ, sponsoring F1 and doing a massive super bowl commercial. https://www.youtube.com/watch?v=jTGSyfvQoZ8&t=367s

"... no obviously we're not going to do any of these things, it comes down to product, product, product"

Re: Neo4j raises $325M series F

#133

Post by tgtweak » Sat, Jun 19, 2021, 12:57 PM UTC

jexp wrote: post #30

tgtweak wrote: post #24

I always find it amusing how much graphQL there is without actual graph db behind it. 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…

Not sure if you saw our graphql integration, that takes typedefs and converts a graphql query into a single cypher query, which can then be executed directly. https://neo4j.com/product/graphql-library/ has links to docs and api scaffolding tools. When I started back then in 2016 with it, it was pretty cool how directly graphql mapped to the graph model in the db.

This looks pretty cool, directly speaks to what I was talking about re: why doesn't more of this exist.

Re: Neo4j raises $325M series F

#134

Post by zestyping » Sat, Jun 19, 2021, 7:45 PM UTC

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.

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.

Re: Neo4j raises $325M series F

#135

Post by redbar0n » Thu, Jun 24, 2021, 1:56 PM UTC

vincent-toups wrote: post #61

handrous wrote: post #51

Earlier quoted context omitted.

Neo4j is all-in on, "almost everything looks like (or can be made to look like) a graph, so almost everyone should be using a graph database". As for those specific figures, I'm guessing there's enough wiggle room in "data and analytics innovations " (emphasis mine) to find or project almost any trend one wishes. What are data analytics innovations ? Why, it's the set of things that will see 80% use of graph technolo…

"Everything looks like a graph" is more damning of the idea of a graph as storage than it is praise. The whole point of a database is to impose _additional_ constraints on the data to ease subsequent application development or data analysis. Relational data may be a hassle but its a hassle you end up having to deal with anyway at some point. I can see a graph database as being a useful place to stash a ton of shitty…

the point is that "to ease subsequent application development or data analysis" can be done just as well, or better, by a graph DB. You don't have to end up with the hassle of relational data as in an RDBMS.