So, 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
I 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).
Benchmarks are so misleading not only because of all the tunable parameters to make these hardly an Apples to Apples comparison, more fundamentally the way you would optimize for different engines involves different trade-offs, different data models with different indexes...
I'm pleased to see SurrealDB making progress. I look forward to the distributed comparisons. Can you also report TPC benchmarks? Also, do you have any write ups on your correctness- and regression testing approach?
I wish they would have compared with Google’s spanner db. I’ve found this database to be the fastest, multi region, globally distributed database by far.
SQLite benchmarks are deeply flawed. Somebody has proven that it can sustain 4M queries per second on bare metal, 1.5M qps on a cloud VM, and it happened over 7 years ago. Therefore I do not believe any number from SurrealDB.
12 comments
[ 0.22 ms ] story [ 45.5 ms ] threadFor 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.
I greatly appreciate when a vendor is willing to run the test and publish unfavorable information, even if it's only in one benchmark category.
Regarding the benchmarks themselves, they would've been more interesting with reproducible steps and more hardware variety.
To your point on the benchmarks, this is something we can improve on documenting and will do so for our next release.
https://use.expensify.com/blog/scaling-sqlite-to-4m-qps-on-a...