Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
1–10 of 35 posts
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#2[deleted]
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#3So, just use PostgreSQL? 50% faster write at cost of 25% slower reads (which usually are prevailing workload) doesn't warrant moving into far smaller ecosystem
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#4I really wish they clearly documented the parameters used by each of the databases (or are we expected to dig those out of the .rs sources somehow?), and actual versions used (saying "Postgres" is ambiguous, it could be 14 or 18 - presumably it's 18, but who knows).
For example, I see they do this for Postgres:
`let max_wal_gb = (shared_buffers_gb).clamp(2, 16);`
2-16GB of WAL is not a lot, but I have no idea how large is the data set.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#5So, just use PostgreSQL? 50% faster write at cost of 25% slower reads (which usually are prevailing workload) doesn't warrant moving into far smaller ecosystem
Postgres is definitely one of the strongest databases out there, and we are not trying to hand-wave that away with benchmarks. The point is more that SurrealDB v3 is getting much closer on raw performance while offering a multi-model database, which feels especially relevant today.
On the ecosystem side, we have also grown a lot over the last few years across the community, integrations, cloud offering, and customers. Still work to do, but we are not as far off as people might assume.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#6So, just use PostgreSQL? 50% faster write at cost of 25% slower reads (which usually are prevailing workload) doesn't warrant moving into far smaller ecosystem
Projects that's using already existing that is using Postgres already should keep it in Postgres.
It is worth a try for startups if you won't mind. Try to vibe code around it and give the data model a new look. I have a prototype project that combines both tree-sitter AST and converted it to JSON, then since SurrealDB accepts JSON as native input I now get free graph lookup on the control flow and easily did ancestry analysis and finding what functions potentially calls to this segement. All of it is in SurrealDB nested graph queries and the performance is alright, but is abysmal in Postgres JSONB since JSONB does not linearize the JSON data structure.
ps: I'm building a K8S operator for deploying SurrealDB with TiKV operator integration too.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#7So, just use PostgreSQL? 50% faster write at cost of 25% slower reads (which usually are prevailing workload) doesn't warrant moving into far smaller ecosystem
Not in anyway related with the surreal folks.
I think it is not so clear cut. I mean, the multi-model nature it is pretty neat. Yes, you can use pgvector on PostgreSQL, but here you also have native graph support. If you want to have both you need to also add something like apache AGE, but arguably that is also a small ecosystem (at least IMHO as I never heard it until I actually started looking for Neo4J alternatives). Also, pgvector has a hard limit on embedding size, while surrealdb does not. For instances in which you have less than 1M elements and retrieval performance matters surreal already has an advantage.
In my personal opinion is a great overall product. Probably not the best at anything, but close enough without having to fiddle with PostgreSQL extensions or adding another piece of machinery to support graph workloads.
The only thing I don't like is that they didn't use either pure SQL nor Cipher for the query(ies) language(s). They roll their own blend, meaning that you will likely need more work to move in the ecosystem and you can't fully use the muscle memory of users that worked with other DBs before.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#8I really wish they clearly documented the parameters used by each of the databases (or are we expected to dig those out of the .rs sources somehow?), and actual versions used (saying "Postgres" is ambiguous, it could be 14 or 18 - presumably it's 18, but who knows). For example, I see they do this for Postgres: `let max_wal_gb = (shared_buffers_gb).clamp(2, 16);` 2-16GB of WAL is not a lot, but I have no idea how lar…
We definitely should make that clearer in the docs (thanks for highlighting this). The Postgres image used is Postgres 17.
On the parameters, the relational tests use 5 million records per test. The exceptions are the key-value category, which uses 15 million records, and the embedded category, which uses 1 million records. The same dataset shape, workload, harness, and hardware are used across the engines being compared.
For WAL, the 2 to 16 GB range is not intended to be a limit based on the dataset size. For the published runs, the dataset is small enough that this should not be a bottleneck. The persistent runs are also full-durability runs, with Postgres using fsync and synchronous_commit.
We will update the benchmarks page so the versions, dataset sizes, and tuning details are easier to find without digging through the Rust source.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#9So, just use PostgreSQL? 50% faster write at cost of 25% slower reads (which usually are prevailing workload) doesn't warrant moving into far smaller ecosystem
What is correct depends on your workload. There is never a case for comparing the performance for Postgres vs Redis. The are intended for very different uses and so they are should never substitute, as a feature analysis will reveal which you really need.
Though to be honest most people won't scale enough that DB performance is important in the first place. For most people they don't even need a database, your language has built in containers that will do everything you need.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#10the surreal docs should not say "surreal is open source", it's source-available under the BSL