Hacker News new | ask | show | jobs
by CharlieDigital 1288 days ago
Had the exact opposite experience with N4j.

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.

3 comments

800 concurrent users and millions of nodes sounds quite small. I would expect 800 users to fit on a single Postgres or even SQLite box, if you’re read-heavy.

> Very surprised that people had issues with it.

They may have several orders of magnitude more data & users than you

> I would expect 800 users to fit on a single Postgres or even SQLite box

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.

AFAIK they use MSSQL, not postgres. And they only use one (another is a replicated hot spare) for Stackoverflow.
> 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.

I guarantee that whatever traffic is getting past their cache is still 100x higher than 90% of startups.. People really do try to run before they can walk.
Our customer's use case only specified 200 concurrent so the hardware was set up accordingly.

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.

TLDR: your size is not size
You're kind of missing the point. All performance tests are relative to the expected load and infrastructure design to serve that load. No, it's not Twitter because it wasn't a public facing web app. The point being that in an infra designed to serve 200 concurrent in an enterprise scenario, Neo4j could have served multiples of that for the specified infra OR could have been deployed on smaller infra. We found it quite efficient and easy to tune.
Could it because many people are evaluating the community version of the database? The enterprise/Aura (cloud) is definitely designed to be more scalable
There's no such thing as "scale" with community edition.

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.

Could be.

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.

My app is serving thousands of concurrent users with tables of billions of rows with postgres powered by just 4 CPUs and 20GB RAM.