3 ms·

The coolest thing to me about neo4j is that it spins up a little web server with an extremely friendly UI that allows people to build queries and run then local

The coolest thing to me about neo4j is that it spins up a little web server with an extremely friendly UI that allows people to build queries and run then locally. My non-coder coworker wrote all her own queries and found, then fixed errors in the data entirely on her own. Our data set could have been handled fine with a relational database, honestly. However this was a rare case where over-engineering a problem and using the latest technology saved time.

rspeer 9y ago
So I used Neo4j in 2011. It was very exciting at first, and then I got quite burned by it when I tried to make something real. Many people in this thread are describing a very different experience, and I want to know if it has really dramatically improved, or if the use cases of Neo4j users are just different from mine. - In 2011, it worked great on small data that fit in RAM, but once the data became bigger than RAM, queries would take unexpectedly large numbers of seconds. How much data do you put into Neo4j? - I admired the friendly little web server until I realized that it was a massive security hole: anyone who could access it could run arbitrary code on the server, it ran over plain HTTP, and if you put it behind an HTTPS proxy, it stopped working. I hope this isn't still the case. Does it have reasonable access control and HTTPS now? Could you use the Web interface in production?
- jexp 9y ago
  It runs authenticated enabled by default and uses https and also our binary (always-TLS) protocol. Every database benefits from having the _hot_ dataset in memory, so that's the same with Neo4j. 2011 was many years ago, since then the memory management has been completely rewritten. You very probably wouldn't use the Neo4j Browser in production as it is meant to be a developer tool. Usually, you would build an app that uses the drivers to connect to the db.
- jakewins 9y ago
  On (1), the memory layer has been entirely rewritten since 2011. It used to be a combination of MMAP and on-heap caching; mmap in java being notoriously terrible and caching on the heap being even worse. The memory layer now works similar to postgres, with a user-space page cache managing blocks of RAM. So: It's certainly changed, and in my experience much for the better. On (2), yes, the little UI now requires a username/password, and it supports HTTPS. HTTP remains available, defaulting to localhost access.

rspeer 9y ago

So I used Neo4j in 2011. It was very exciting at first, and then I got quite burned by it when I tried to make something real. Many people in this thread are describing a very different experience, and I want to know if it has really dramatically improved, or if the use cases of Neo4j users are just different from mine. - In 2011, it worked great on small data that fit in RAM, but once the data became bigger than RAM, queries would take unexpectedly large numbers of seconds. How much data do you put into Neo4j? - I admired the friendly little web server until I realized that it was a massive security hole: anyone who could access it could run arbitrary code on the server, it ran over plain HTTP, and if you put it behind an HTTPS proxy, it stopped working. I hope this isn't still the case. Does it have reasonable access control and HTTPS now? Could you use the Web interface in production?

jexp 9y ago
It runs authenticated enabled by default and uses https and also our binary (always-TLS) protocol. Every database benefits from having the _hot_ dataset in memory, so that's the same with Neo4j. 2011 was many years ago, since then the memory management has been completely rewritten. You very probably wouldn't use the Neo4j Browser in production as it is meant to be a developer tool. Usually, you would build an app that uses the drivers to connect to the db.
jakewins 9y ago
On (1), the memory layer has been entirely rewritten since 2011. It used to be a combination of MMAP and on-heap caching; mmap in java being notoriously terrible and caching on the heap being even worse. The memory layer now works similar to postgres, with a user-space page cache managing blocks of RAM. So: It's certainly changed, and in my experience much for the better. On (2), yes, the little UI now requires a username/password, and it supports HTTPS. HTTP remains available, defaulting to localhost access.