More info and can be found on a previous Hacker News post here https://news.ycombinator.com/item?id=32550543
Fireship has made two fantastic videos about SurrealDB https://www.youtube.com/watch?v=C7WFwgDRStM https://www.youtube.com/watch?v=LCAIkx1p1k0
Alternatively join us on Discord to ask any questions you have on our database https://surrealdb.com/community
Thank you and have a great day/night!
Coukd you elaborate on that or point me to the right direction?
Thanks!
We're also looking to improve our roadmap page soon, which will detail everything we're working on and planning to work on in the near term, and in the future!
There's plenty of functionality implemented to make it a workable database. It's also still in beta...
I only played around with it for half an hour, but superficially it seems to work fine already.
Wish you all the best as the project grows! \m/
That said, please make GraphQL and Apollo Federation support a high priority. SurrealDB could be a gamechanger but federation would allow it to be integrated into existing supergraphs, which is an enterprise requirement for adoption.
Don’t get me wrong though, it would be a really awesome product with my dream feature set if they can actually pull it off. I wish them the best of luck and it will be very interesting see where SurrealDB ends up in a few years time!
True and if you look inside the code you can see the stated features are a result of underlying engine from those smart people (TiKV [0] in C and rust from pingcap). Surrealdb is standing on shoulders of giants at present, they are TiKV, FoundationDB and rocksdb. The feature set they mentioned mostly coming from TiKV at present.
At the moment (as you have noted) the underlying storage engine is RocksDB (in single mode) or TiKV (in distributed mode), however, although we will always support deployment on top of these solutions, we intend to add our own embedded and distributed key-value stores in due course, which will offer different functionality in the long run!
We're looking to improve our roadmap page really soon to show exactly what we have planned / working on in the near term. In the meantime our features page https://surrealdb.com/features shows details most of the functionality that is already built, or coming in the future.
Free for personal or commercial use. But service providers have to pay if they offer this database as a service.
The LICENSE file even contains the following part:
> The Business Source License (this document, or the “License”) is not an Open Source license. However, the Licensed Work will eventually be made available under an Open Source License, as stated in this License.
And README mentions nothing about FOSS/OSS, so seems the submitter here on HN added it themselves to the title. Should be removed.
However, it is improper to call it FLOSS. Maybe "eventually FLOSS".
(This means that if the Change Date is not altered before then, none of SurrealDB will be BSL any more come 2026.)
We would use it like this but would need to sign a contract somewhere that if support stops, it would, at least for us, drop away that requirement, maybe for a final lumpsum.
Edit; never mind, they already have such a clause! Nice one.
Edit; the project has ‘eventual FOSS’ which I like as a concept and thought of doing myself; put milestones in place which can be externally verified which will trigger the license of the (semi) closed product to become fully foss.
Orbitjs looks interesting for this approach https://orbitjs.com/.
Not sure if there are many different tools following this model.
Wish postgresql could push embeded JS to the extreme.
This isn't so much a value judgement as it is an observation.
Keep your technology boring and make your app interesting, as they say [0]. Given only three innovation tokens, I don't want to burn all my tokens on something the end user won't even see.
Given concrete requirements or use cases it would be easier to compare given DB solutions, but when people are scoping something for say a new project, or a personal project (flexible requirements / motivation), how does that usually go down? If anyone has first hand experience on this :)
Either way, it always helps to have some basic use case in mind. Bigger than "Hello, World" and smaller than a MVP. The outcome of any evaluation will heavily depend on whether it's a good fit for what you're trying to achieve.
Then when I'm motivated, and find a DB that's really interesting, I force myself to use it (like couchDB) in order to learn my way around it.
That's how I decide what to use.
I would suggest changing the description to better distinguish between what's currently available and what's a future plan to match the features page.
This is also confusing; there are no mobile bindings that I can find.
I wish you success though, to the point where those issues I mentioned are no longer true.
But... I have a project I've been planning in mind for a while, I'd like to use it for this.
There is no documentation.
Any big difference between them?
Please don’t include “built on Rust”.
Please leave this at the door, we have plenty of posts with "built in Zig" in the title too. It's not even remotely a big deal.
Came across this rather interesting issue on their own repo: https://github.com/surrealdb/surrealdb/issues/103
I think it's time we say "Stable Diffusion Powered Hyperfast Scalable Ultimate Cloud-Native Kubernetes Native Document Graph Relational NewNoSQL Database"
Enough of the buzzwords on HN, honestly. Also, NOT FOSS.
