SurrealDB: Distributed document-graph database for the realtime web
github.comThanks for posting this dragonsh! I am Jaime, Founder of SurrealDB with my brother Tobie. Just the two of us at the moment but we have some some really big things planned for the database. Any feedback is really welcome!
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!
Hey! I see you mention graph relations, and was wondering if it would be possible to use SurrealDb to store data about eg people and events and query the database to retrieve "proximity" out of that data, ie number of "hops" between two or more people.
Coukd you elaborate on that or point me to the right direction?
Thanks!
Apart from your buzzword marketing, what features are actually available for use today? Most are "on the roadmap." Reminds me of Spacedrive which literally launched with a "nice UI" and no actual features that they advertise for.
Hi johnwoods - Tobie founder of SurrealDB here. We're updating our website so it's clearer, but in the meantime, the best page to see the current functionality is our features page https://surrealdb.com/features
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!
Looking at the features page, this feels like inappropriate criticisms.
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.
Hi Jaime, this is my first time hearing about SurrealDB and it looks awesome! Do you have any documentation outlining the system architecture and how it works under the hood? Thanks for the great work!
Gotta admit, for a 2 person team, the project codebase and the marketing around it (website/community) are very well done
Wish you all the best as the project grows! \m/
You might know this already, but what you are creating here is future state-of-the-art.
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.
Looking through the SurrealDB website and marketing copy, I can’t help but be a little bit skeptical of the feature set [1]. Many, many smart people have burned many millions of dollars and thousands of man hours building databases claiming far fewer capabilities.
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!
> Many,many smart people…
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.
I think TiKV is pure Rust no?
TiKV is written in rust but then it depends on crates which use C and libc. Rust complements C, it is not an alternative to C, just another alternative to C++.
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.
Rust is absolutely an alternative to C. The fact that Rust currently depends on C libc on some platforms is a pure implementation detail, and I believe there is ongoing work to remove that dependency.
C is implementation detail and that's what make it irreplaceable in short period of time. In my view Rust story will be similar to C++ if it continues to stay relevant for next 20-30 years and will be another alternative besides 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.
> Right now Go is miles ahead of Rust when it comes to libraries and ecosystem.
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'm not sure that's true
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.
It does use RocksDB which is c++. But the result would probably be less stable if that had to be Rust as well.
You can use it now, 1.0 is in beta and does all the things they advertise, I'm starting to dig into it and it's very legit from what I've played with
I tried searching for what kind of GraphQL support they offer on their repo (which is an advertised feature) and it still seems to be a WIP, though you have to kind of dig through the readme to find that out. Same problem with the full-text indexing feature, as another user here mentioned.
Hi user1029384756 - Tobie here, founder of SurrealDB. We do plan to support GraphQL integration soon (hopefully before our final 1.0 version). Our features page https://surrealdb.com/features is the best place to see what is built, and what we intend to build in due course! Hope this helps!
Hi user1029384756 - Tobie here, founder of SurrealDB. It's just a team of 2 of us at the moment, with the intention to grow the team very soon!
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.
I'm going to go on a limb an guess that its performance or memory usage will be terrible compared to traditional databases
Development velocity, however, could be off the charts with this kind of solution, as long as everything works as expected.
Business source license.
Free for personal or commercial use. But service providers have to pay if they offer this database as a service.
Wow yeah that's true! I was interested in looking closer into Surrealdb until I noticed this.
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.
The term `FOSS` should be removed from the title
It is now removed.
But the good part of BSL is that after 4 years it becomes true FLOSS, in this case Apache v2.
However, it is improper to call it FLOSS. Maybe "eventually FLOSS".
Eventually open source is something I really do like, but it should have clear, measurable and open milestones for doing so. Like Open Accounting to show ‘if we reach 100k’ or something like that. Or if we reach 1000 contributors or if we reach 50k in donations. One thing bloody ETH would be useful for; it would be impossible to hide and you cannot change your mind on when the switch flips.
It’s all there in the license: https://github.com/surrealdb/surrealdb/blob/main/LICENSE. It reverts to Apache-2.0 after four years of the release of a particular version, or on 2026-01-01, whichever comes first.
(This means that if the Change Date is not altered before then, none of SurrealDB will be BSL any more come 2026.)
Yep, I saw it; edited my other comments to say it's there. Nice one!
Not ideal, but doesn't seem entirely terrible either
Not terrible but I think it should have a clause that if they stop supporting it (go out of business) it drops to apache or something. Their call of course; not for anyone else to say.
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.
This sounds like great work; been playing with graph dbs lately and it makes things easier. I was hoping though that there would be an effortless offline component to it though; maybe I missed it but there seems to be none? We have been trying to find a replacement for couch/pouch which gives the same convenience as that combo (besides setting up the right filters and permissions, everything works automatically). I see many people rolling (usually very hacky ‘cache invalidation’) solutions which require a lot of domain knowledge where pouch just works and querying server and client (mostly) the same way also lightens the load a lot. Couch is old and works very well, but, besides being very good at synching, it has a lot of downsides which we just ignored (which worked for us for a decade and very well at that), but with we are not good with couch (erlang) as rust/go/ts team and with the advances in webasm and anything-to-js, as well as having bucketloads of memory and storage on most non-iot (but even some of those if done with care) edge devices these days, you would think there would be a solution that allows me to do this outside couch/pouch. Of course here I forget to mention; although we would not mind paying for it, it needs to have an actual OSS license (not open core but apache/mit/bsd or whatnot). And yes, we might have a go at it ourselves but we are swamped at the moment.
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.
+1 here. I have already seen some videos with people toying with surrealdb and it looks amazing. But I need a offline-first (local-first) solution. Recently, TinyDB was posted here at HN. I also heard of InstantDB (react only).
Take a look at RxDB https://rxdb.info/
After many experiments we found that it makes a lot of sense to handle these things at the data access layer and not make your project depend on some special kind of data store.
Orbitjs looks interesting for this approach https://orbitjs.com/.
Not sure if there are many different tools following this model.
Really liked this summary: https://youtu.be/C7WFwgDRStM
I’ve made quick and messy SurrealDB usage example for authentication and user data storage in a Flutter app: https://github.com/wrbl606/flutter_surrealdb_client_example
This is really perfect ORM layer i'm looking for (mostly because of scalability and embeded JS capability). Thanks!
Wish postgresql could push embeded JS to the extreme.
To be honest I haven't used it, but I've extensively used pl/pgsql and a little pl/ruby, and know that https://plv8.github.io/ exists - it might be what you're looking for and it's on my list of things to play with
This title sounds like a buzzphrase generated by GPT-3 if it were fed a corpus of nothing but HN titles. I haven't actually read the article, but the only way it could sound more like an HN post is if it mentioned Nix.
This isn't so much a value judgement as it is an observation.
"A graph database for NixOS written in Rust, illustrated with Stable Diffusion"
I've been down this road multiple times with Arango DB, and Orient DB and IDK how many others. Doing too much of everything usually means not good at everything. I will stick to doing one job good, and battle tested tools.
Indeed. At this point if I'm building an app, I don't want surprises in the technology side. If I hit a problem, I'm more likely to find a solution had I used Postgres than had I used the database du jour, SurrealDB in this case. I'd much rather go through composing building blocks together (Apollo GraphQL with Postgres) than depending on one tool to do them all well, because if one part sucks, at least I can swap it out.
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.
How has your experience been with arango? I haven't had any major issues with it. It runs exceptionally well in kubernetes too.
Noob here - how do people usually assess DBs to one another? Why should I use this say over DynamoDB?
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 :)
If your spec is entirely up in the air, you can start by replicating the examples. Lack of meaningful examples and/or in-depth documentation is the first red flag. You can also scan the reported issues to see if others are having trouble with core features, which is a sign of project immaturity.
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.
Great point on being able to use motivating examples and testing out how user friendly the documentation and "getting started" is.
Not sure if relevant, but for me, when I want to develop quickly and reliably, I go with mySQL, because that's what I know best.
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.
The "What is SurrealDB" page says "with support for... full-text indexing" which implies that SurrealDB has that now, but the features page lists "Full text indexing and filtering" as "future"
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.
> cloud native database for web, mobile, serverless, jamstack, backend, and traditional applications.
This is also confusing; there are no mobile bindings that I can find.
Previous discussion, 4 weeks ago: https://news.ycombinator.com/item?id=32550543
The websocket aspect they are working on is actually the only feature that really interests me. Direct notification from the DB on updates is insanely useful. Think of how easy it would be to build a real time app like a chat. No more long polling. No more websocket layer that polls the database.
I like this project ... but the functionality you are describing sounds like something that Postgres LISTEN/NOTIFY offers.
The value here comes from the database being able to service the websocket itself, if I read this right. So you don't have to do this in your application.
I see. I would be curious to see how that actually works out in a live environment at scale.
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.
Stores like Redis and message queues have had pubsub updates for ages…
That was the previous HN post. Has much changed since then?
cool project, reminds me a bit of arangoDB, but here even more logic can be built into SQL, allowing to develop (almost) the whole backend logic into the DB. The main problem with this kind of technology is that you move logic from established programming languages (java, C#, go, ...) to something more exotic which only a few programmers know. The other problem is lock-in, if the project dies you have to rewrite all your backend.
I wish you success though, to the point where those issues I mentioned are no longer true.
Does is support Cypher?
I Ctrl+f'd the readme but no match.
I really hope this, or something like it, ends up succeeding massively. Someone needs to put a bullet in SQL so that we can innovate properly in this space.
Ok I read more about it and I agree with the sentiment.
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.
Feature set looks promising
I really need this to take off and be as good as advertised! I can't afford the risk of being an early adopter tho.
Does it similar to supabase?
Any big difference between them?
Please don’t include “built on Rust”.
>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.
That's a hell lot of buzzwords (GPT-3 trained with HN titles, eh?). Does "serverless" and "cloud-native" database together even make any sense? Idk, but I feel like these folks are doing too much pointless marketing when the core product literally just "borrows" code from other databases without any credit to them.
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.
Great idea. Too bad it is not Open Source
Tfnylb3544_