Hacker News Reader

Comment by lclarkmichalek | Hacker News Reader

Eugh, Neo4J. Before you start using a graph database, ask yourself, what proportion of my queries are going to require complex graph traversals? If the answer isn't 'a metric shitton', then you might do better in choosing a more traditional datastore.

View on HN

I could not disagree more. Neo4j has got to be the most intuitive, simplistic database structure on earth. The php client is amazingly optimized, even for super small datasets, it murders sql. The graph visiualizer is beautiful and extremely helpful. I might even argue that it has better documentation than SQL because it's all in one place with instructional videos and tutorials. If you live in silicon valley, you can go to their office for "office hours" and they give you pizza and beer and teach you how to use it. It so simple and easy to use a child could do it.

Simple and easy is not really what I'm looking for in a database. I mean sure those are nice, but they are orthogonal to the important issues, which I'll loosely classify as power. A lot of people flocked to MongoDB based on the promise of ease-of-use plus scalability, but then realized there's no free lunch, and actually learning SQL was a small price to pay for the power of modern RDBMSes. They partied hard with their schema-less designs, pushing code faster than anyone ever thought possible, right up until they learned the purpose and value of data integrity.

This is not to say that Neo4j is just an overhyped fad DB, but saying that the structure is "intuitive [and] simplistic" is not confidence inspiring.

Last time I used Neo4j in production with NodeJS we had only a few thousand nodes, and our heaviest query, which equated to a 2-table-join sql query, took up to 3 seconds to complete. We abandoned it and went with postgres...

I disagree, I've been dabbling with OrientDB (graph database) and found that while graph databases have its own set of complexities, at the end of the day, you get a bit more structure and depth with graph databases.

If you're structuring data with hierarchies, graph databases are highly dependable. Not that you can't do this with SQL it's just more difficult. Not to mention that relational databases have costly JOIN's which is not a thing for graph databases.

I still have nightmares of the terrible, terrible RDF graph database we used at my last job.

We just used a godawful custom-written wrapper around Jena (we open-sourced it, and I thought about linking it, but I'm hesitant to tie this account to my real-life identity).

Oh, and we created our datastores by editing Google Sheets, because our wrapper around Jena also had the ability to parse Google Sheets as RDF stores. Eventually, we moved on to XLSX documents and finally to TTL, but we still did everything by hand.

Reply on news.ycombinator.com