the surreal docs should not say "surreal is open source", it's source-available under the BSL
I'd love to see the OSI mature it's license taxonomy for 2026
Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
11–20 of 35 posts
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#12Benchmarks 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...
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#13So, 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…
Unless you want to build a startup specifically around that new hot database to do something very specific that's hard with other systems, do not build your startup around a hot new database.
The innovation points you spend on this should generally be spent in other areas, not seeing if someone's unproven db is your breadwinner.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#14Earlier quoted context omitted.
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…
Unless you want to build a startup specifically around that new hot database to do something very specific that's hard with other systems, do not build your startup around a hot new database. The innovation points you spend on this should generally be spent in other areas, not seeing if someone's unproven db is your breadwinner.
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.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#15the surreal docs should not say "surreal is open source", it's source-available under the BSL
I'd love to see the OSI mature it's license taxonomy for 2026
The OSI definition is just fine for software licenses. It doesn't need to "mature". The BSL is not compatible with the principles and concept of open source software.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#16Earlier quoted context omitted.
I'd love to see the OSI mature it's license taxonomy for 2026
The OSI definition is just fine for software licenses. It doesn't need to "mature". The BSL is not compatible with the principles and concept of open source software.
I disagree. Current posture makes it nearly impossible for European companies to build software centric open source businesses.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#17Benchmark dataset fits in memory. Not a good test.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#18Earlier quoted context omitted.
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…
Unless you want to build a startup specifically around that new hot database to do something very specific that's hard with other systems, do not build your startup around a hot new database. The innovation points you spend on this should generally be spent in other areas, not seeing if someone's unproven db is your breadwinner.
Well, I'm still in a very early phase, but I'm indeed combining both Restate and SurrealDB together for a project that I'm building, where I persist the temporary state on Restate and permanent state on SurrealDB, and since both uses JSON as its lingua franca, it is pretty easy to serailize data between Restate and SurrealDB, very much so better than using MongoDB with BSON as many people would have naturally thought of what is supposed to be a better replacement than SurrealDB.
Oh, that's the reason the SurrealDB operator was here in the first place because I need the full K8S lifecycle to maintain the database state such as backing up, that is not really doable with Helm.
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#19Earlier quoted context omitted.
The OSI definition is just fine for software licenses. It doesn't need to "mature". The BSL is not compatible with the principles and concept of open source software.
I disagree. Current posture makes it nearly impossible for European companies to build software centric open source businesses.
Why do you think the OSI should be concerned with European companies and their business models? Why would European companies have a more difficult time building software centric open source businesses than companies in other countries?
Re: Benchmarking SurrealDB 3.x vs. Postgres, Mongo, Neo4j and Redis (With Fsync)
#20Earlier quoted context omitted.
Unless you want to build a startup specifically around that new hot database to do something very specific that's hard with other systems, do not build your startup around a hot new database. The innovation points you spend on this should generally be spent in other areas, not seeing if someone's unproven db is your breadwinner.
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.
A good point, though I think most people take the stitch it together approach because they either have existing processes or proven tech (so startups make sense) - however generally picking an all in one often means that the base cases (like getting started) are awesome, but the edge cases are a razors edge (no familiarity with your product).
As a former DBA I got to see the general purpose databases bolt on a lot of shitty addons, and a lot of upstarts build just enough to get the sale done (or targeting bigger customers than I) - I hope y'all can get enough polish and reliability done and grow into something I want to use in five years :)