General consensus is it's really slow, I like the concept of surreal though. Our first, and extremely bare bones, version of the graph db was 1-2 orders of magnitude faster than surreal (we haven't run benchmarks against surreal recently, but I'll put them here when we're done)

Hey George, Alexander from SurrealDB here.

Congratulations on the launch! This is a very exciting space, and it's great to see your take on it.

Running fair benchmarks, not benchmarketing, is a significant effort and we recently put in this effort to make things as fair and transparent as possible across a range of databases.

You can see the results and links to our code in the write-up here: https://surrealdb.com/blog/beginning-our-benchmarking-journe...

We'd be very interested in seeing the benchmarks you'd run and how we compare :)

You can sacrifice many things for faster performance, such as security, consistency levels or referential integrity.

I'm genuinely curious to learn what design decisions you will make as you continue building the database. There are so many options, each with its pros and cons.

If you would like to have a chat where we can exchange ideas, happy to do that :)

I've only just seen this! Thanks so much for the response, would definitely love to chat with you guys.

You're definitely right btw, those weren't concrete benchmarks and I'm excited to see how we compare now :)

> You can see the results and links to our code in the write-up here: https://surrealdb.com/blog/beginning-our-benchmarking-journe...

page says your benchmark runs on 5M of records only. Is it incredibly small dataset in current world, and is it more micro-benchmarking?

Also, count(*) query having 5s latency on 5m records is very underwhelming if I understand your tables correctly.

I don't think that's all the general consensus

I was just going off of what we've heard from users and people in the space, I admit that "general consensus might've been the wrong terminology.