Easy to operate, scale and run. We started in 2014 and in 2018 did a large scale enterprise rollout with a large customer. The performance test we put it through loaded millions of nodes and millions more edges with non trivial data and scaled to 800 concurrent users (could have been even more but for the fact that the web servers we had for this test scenario started to max out since the system was scaled for 200 concurrent and we were basically stress testing it at this point).
In the early days, there were a few edge cases of query incompatibility between versions that we caught with unit tests, but otherwise very stable, easy to operate, and easy to use. Cypher is one of my favorite query languages.
Very surprised that people had issues with it.
We only used the community version for dev, but even that could scale quite well for a single node on SSDs.
But we also spent a lot of time learning how to map our use case to it.
There's no clustering. There's no monitoring. The only user is admin.
But for the low, low, yearly price of half a million dollars you can get the very basics required to run reliable production workloads.
> Very surprised that people had issues with it.
They may have several orders of magnitude more data & users than you
You can serve thousands of concurrent users on less-than-laptop resources -- we do. If you get a big dedicated server you can serve more concurrent users than you'll likely ever have customers. Modern relational databases are just very good.
StackOverflow's stack (https://stackexchange.com/performance) is 4 huge Postgres servers. They probably cost less than our AWS bill for a couple months, which makes me jealous. Postgres scales.
Yeah, because everything is actually served from their caches because they're extremely read heavy.
2016 https://stackoverflow.blog/2016/02/17/stack-overflow-the-arc...
2022 https://hanselminutes.com/847/engineering-stack-overflow-wit...
1.5 TB RAM
We stressed it to 800 and N4j was fine and had tons of headway while the web servers started to give out (high CPU and mem).
Customer use case would never see 800 concurrent so it was a non issue in our case.