[jitl]

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

[dj_mc_merlin]

> 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.

[littlecranky67]

AFAIK they use MSSQL, not postgres. And they only use one (another is a replicated hot spare) for Stackoverflow.

[sofixa]

> 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.

[pmontra]

They use SQL Server

2016 https://stackoverflow.blog/2016/02/17/stack-overflow-the-arc...

2022 https://hanselminutes.com/847/engineering-stack-overflow-wit...

1.5 TB RAM

[dj_mc_merlin]

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.

[CharlieDigital]

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.

[ZephyrBlu]

TLDR: your size is not size

[CharlieDigital]

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.