itsezc

All of our releases thus far are source available, and will be open source 4 years from the release date.

To your point on the benchmarks, this is something we can improve on documenting and will do so for our next release.

Your reasoning is very solid, and something I'd also consider before picking a DB.

No one should pick us because we're the new hot thing (at least I'd hope not). But at SurrealDB, we've got real enterprises in production at scale. For a lot of startups building today, having LLM/vector features, graph, auth, and the database in one place can really help you ship faster without stitching a bunch of tools together.

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.

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.