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.
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.
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.
Not so much whether the code will be performant enough to service concurrent websocket requests, but other operational concerns such as, websocket balancing across the cluster, authentication and access logs, failure modes, or usage isolation, just to name a few things off the top of my head.
May be 20-30 years down the line, if it stays may be enough OS and libraries are built in native Rust without C then it might displace it, but at the moment Rust depends on C.
Right now Go is miles ahead of Rust when it comes to libraries and ecosystem. So it needs to catch up and once it overcomes Go popularity it might be nearer to C++. C is a different beast and will continue to be there it's the lingua franca of hardware programming and abstraction, unless something simpler comes and takes over which will also be 2-3 decades.
I'm not sure that's true. A couple of years ago sure, but Rust is growing very fast.
I also think there's no reason to think C will stay around forever. The C ABI will be the lingua franca, but that doesn't mean you need to actually use C.
The only reason it has persisted for so long is lack of alternatives, but now we have at least Zig and Rust. Obviously there's a ton of momentum so it will still take a while to be replaced but I wouldn't be surprised if e.g. musl switches to Zig or Rust fairly soon.
I am sure its true, given Kubernetes, Docker and related projects, CockroachDB, prometheus, influxdb, nomad, otto, consul, grafana, terraform, snap, juju, Caddy, SeaweedFS, minio, milvus, syncthing, cilium are some of the examples in Go. Indeed it will be safe to say Go is one of the prominent language like Java, Python, C, C++ powering the internet. Rust still has a mountain to cross to reach even half as much usage as Go, except TiKV, Rust itself and Servo I don't see large open source software in Rust yet.
There is a lot of talk about it on HN and may be given 20-30 years it might become more widespread. Rust is still recovering from its failure of Servo not being used by Mozilla, given it failed to live up to expectations of replacing C++ in Firefox due to performance issues and resolving them within time constraints of project budget.