Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neo4j raises $325M series F

neo4j.com

Post reply on HN
Print view View original

81–90 of 135 posts

Re: Neo4j raises $325M series F

#81

Post by dfraser992 »

zozbot234 wrote: post #76
dfraser992 wrote: post #71

Earlier quoted context omitted.

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 "…

For what I was doing, and how I was doing it, working with graph structures directly with Cypher would have been easier. Perhaps "logical" is the wrong word; my intent was to relay my specific experience, not express a general "principle".

Re: Neo4j raises $325M series F

#82

Post by lumost »

AzzieElbab wrote: post #79
zozbot234 wrote: post #58

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

At the end of the day Neo4J needs to operate a query planner on top of a relatively standard index structure to present the graph abstraction. There is limited difference between Neo4j's planner and what could be planned from SQL.

GraphDBs make more sense when there is strong evidence that either the natural description of the program is a graph or that the underlying storage engine can efficiently model the graph.

So far no GraphDB has demonstrated either statements as true for the majority of problems.

Re: Neo4j raises $325M series F

#83

Post by ako »

zozbot234 wrote: post #75
deckard1 wrote: post #68

Earlier quoted context omitted.

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.

Or use Odata: rest, with all the benefits of graphql, and aggregations, grouping, joins, filtering, sorting.

Re: Neo4j raises $325M series F

#84

Post by zozbot234 »

AzzieElbab wrote: post #79
zozbot234 wrote: post #58

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

There's admittedly some ongoing work on extending the SQL standard syntax with some extra sugar for "Property Graph Query". But there's nothing wrong technically with just using basic SQL syntax, it's just a matter of getting it to work. Performance will vary depending on query optimizer, any INDEX definitions, etc. and is quite a separate concern.

Overall, graph databases are so general as a model that writing slow queries will always be a possibility, so one should be mindful of these concerns. But that's just as true in NoSQL graph db's.

Re: Neo4j raises $325M series F

#86

Post by zozbot234 »

__jem wrote: post #85

Curious what something like Neo4j offers over a something like [this]( https://docs.microsoft.com/en-us/sql/relational-databases/gr... ) in MSSQL.

These seem to be non-standard SQL extensions, AIUI. At least Neo4j has something of a quasi-standard solution for their querying layer, that might also be supported by other vendors. These extensions are a dead end.

Re: Neo4j raises $325M series F

#87

Post by hirako2000 »

xibalba wrote: post #69

According to Crunchbase, Neo4j was founded in 2007! Is this correct? 14 years in and they are still raising VC money!?

Welcome to the new economy. VC money get poured with an exit at sight. The bags keep growing until it ends up on public offering.

By that time, the share is pretty much what it's worth. But 100 times round A. If all went well of course. Over 90% of the time, it didn't go well. Who knows how that will end for Neo4j, but the investors have their eggs in many other baskets anyway.

What matters isn't showing profit anymore, not even significant revenue to justify further funding. All you need is some appealing growth figures, sometimes not even that, just a convincing argument that hyper growth is on the horizon.

At some point millions are put into advertising and a strong sales force to grow revenue many folds. In the enterprise market, the trick often works pretty well.

Re: Neo4j raises $325M series F

#88

Post by ants_a »

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 additional constraints are also what enable performance optimizations. And not the small ones, the ones that give orders of magnitude improvements. Whereas right now neo4j is slower for graphs than postgres, just with a nicer UI.

Re: Neo4j raises $325M series F

#89

Post by slver »

softwaredoug wrote: post #40

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

Those investors will never see that money again

Re: Neo4j raises $325M series F

#90

Post by __jem »

zozbot234 wrote: post #86
__jem wrote: post #85

Curious what something like Neo4j offers over a something like [this]( https://docs.microsoft.com/en-us/sql/relational-databases/gr... ) in MSSQL.

These seem to be non-standard SQL extensions, AIUI. At least Neo4j has something of a quasi-standard solution for their querying layer, that might also be supported by other vendors. These extensions are a dead end.

I’m not sure I understand calling this a “dead end”. Almost no one limits themselves to pure ANSI SQL. Pretty much any application of reasonable size in production uses vendor specific APIs. A “quasi-standard” is not a standard.

I was thinking more about technical reasons in terms of the storage layer. The query syntax seems to be the least interesting part of a database, to be perfectly honest.

Post reply on HN