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

121–130 of 135 posts

Re: Neo4j raises $325M series F

#121

Post by mycall »

zozbot234 wrote: post #84
AzzieElbab wrote: post #79

Earlier quoted context omitted.

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…

Also, nested sets and materialized paths have been around forever to do graphs inside SQL.

Re: Neo4j raises $325M series F

#122

Post by DSingularity »

somewhereoutth wrote: post #48

Graph DBs work if you know your relationships of interest ahead of time, and are happy to have them baked into your dataset. With relational databases, you can join on anything anywhen, so you can explore new relationships as you go.

> Match (a)-[:knows]-(b) > Match (b)-[:loves_to_eat]-(c) > Return a.name,c.name //food suggestions

Why isn’t this sufficient to explore novel relationships?

Re: Neo4j raises $325M series F

#123

Post by heldsteel7 »

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.

We did evaluate Neo4j, but put down due to its complex query language (cypher) and slowness. It was really an awkward language, super awkward.

We also evaluated arangodb and we found it much better than Neo4j. Performance was good and its query language was better too.

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.

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.

Re: Neo4j raises $325M series F

#124

Post by jhanschoo »

deckard1 wrote: post #68
handrous wrote: post #35

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.

I wonder how much of that naming has to do with FB's Open Graph APIs.

Re: Neo4j raises $325M series F

#125

Post by zurfer »

feu wrote: post #36
Grimm1 wrote: 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.

We use ArangoDB and are super happy. But I guess it depends on your use case. We operate in the area of 1 million records. Everything is super fast and the ability to also have search, graph and document workloads was most important for us.

Re: Neo4j raises $325M series F

#126

Post by fedder »

Barrin92 wrote: post #97
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!?

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

Re: Neo4j raises $325M series F

#127

Post by diveanon »

Neo4j can be a useful supplement to apps that have data models that include graphs.

If you are using relational db you can use recursion to achieve the same effect without having bring n4j and cipher into your stack.

A simple example of implementing a hierarchical graph data structure on postgres and exposing it via graphql can be found on the hasura blog.

https://hasura.io/blog/authorization-rules-for-multi-tenant-...

Re: Neo4j raises $325M series F

#128

Post by tango12 »

diveanon wrote: post #127

Neo4j can be a useful supplement to apps that have data models that include graphs. If you are using relational db you can use recursion to achieve the same effect without having bring n4j and cipher into your stack. A simple example of implementing a hierarchical graph data structure on postgres and exposing it via graphql can be found on the hasura blog. https://hasura.io/blog/authorization-rules-for-multi-tenant-.…

(from Hasura) I've been wanting to try out a thing and use Neo4j + Postgres simultaneously. Use Postgres for data, Neo4j for relationships and graph-y queries.

Has anyone tried that? Would love any notes/pointers!

Join data across the two to get the best of both basically. Hasura doesn't support Neo4j natively yet, but maybe using Neo4j's graphql wrapper as an input to Hasura perhaps?

Re: Neo4j raises $325M series F

#129

Post by evdevreed »

zozbot234 wrote: post #84
AzzieElbab wrote: post #79

Earlier quoted context omitted.

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…

Something I just found out after looking into status updates on the Property Graph Query (PGQ) work being done in SQL, is that it will exactly mirror the work going into GQL (Graph Query Language, a newish standard in its early stages of development based mostly off of Neo4j's Cypher).

To summarize this post[0] by someone involved with the standards:

- GQL (ISO/IEC 39075) is a full database language to create and manage property graphs and create, read, update, and delete nodes and edges (or vertices and relationships)

- SQL/PGQ (ISO/IEC 9075-16) is a new add-on part of the SQL standards which introduces the capabilities to create property graph views on top of existing tables in an SQL database, as well as the ability to query property graphs using a GRAPH_TABLE function in an SQL FROM clause

- The input to the SQL/PGQ GRAPH_TABLE function is a property graph query, sometimes referred to as Graph Pattern Matching or GPM. Graph Pattern Matching is common between SQL/PGQ and GQL. That is, the syntax accepted in a GRAPH_TABLE function in an SQL FROM clause is identical to the syntax in a GQL graph query. Because GPM is the same in both draft standards, changes to GPM for SQL/PGQ also apply to the GPM portions of the GQL specification.

---

I also just came across the Apache AGE project[1] which basically allows you right now to extend PostgreSQL DBs with property graph capabilities and enables full(?) use of Cypher/GQL.

[0] http://www.jcc.com/resources/jcc-blogs-menu/blog-database-dr...

[1] https://age.incubator.apache.org/

Post reply on HN