Hacker News Reader

Comment by tobiemh | Hacker News Reader

Thanks for posting this nerdyadventurer! I'm Tobie founder of SurrealDB. We've got some really big things planned for the database. Any feedback is really welcome!

View on HN

Hey, random tangential question: Why do you have `user-select: none` on the page? is there a reason that you don't want people to be able to copy/paste any of the paragraphs? Or is there some other reason

(I noticed as I found it jarring since I'll often select text while I'm reading it.)

EDIT/NOTE: Also, I imagine it might somewhat hurt things getting spread by word of mouth. If I wanted to share this with someone I'd naturally copy some sections, paste them into a message to someone that might be interested along with a link to the site. This isn't possibly with your landing page.

Hi mijoharas, no reason to be honest! It's just what we've done for other sites we've built in the past - a design reason more than anything else!

You're not the first one to make this point, so we'll get this removed from our site!

That's a really good note/point/addition mijoharas. We'll get it changed ASAP!

No worries, and no rush or anything. Was really just curious more than anything!

What's the underlying storage engine? I've been doing some design work on a new hybrid LSM/Extendible Hashing system in Rust and am curious what this is using underneath.

Hi packetlost. Currently the underlying storage engines are memory, and distributed TiKV. For the next beta release (coming this week) we also have a local RocksDB implementation and a distributed FoundationDB storage implementation.

In the long run, we want to implement our own key-value store so that we can offer some of the temporal/versioning aspects (which would allow you to view your data in the graph as it appeared at a particular point in time).

For the browser, SurrealDB sits on top of a key-value store which is powered by IndexedDB, so that SurrealDB can run in the browser, using WebAssembly.

My hybrid LSM/Ext. Hash system may be of interest actually. It's purpose built for tracking historical data similar to Datomic's data model, but emphasizing constant-time read operations for current data while keeping the read speeds for historical data reasonable. In short: 2 level LSM tree (log file, immutable page files) with a extendible hashing to index into the page files. The identity of each record is the key + tx instant (time of COMMIT, or some other monotonically increasing number that is unique to a transaction set). Optionally you can index over historical data by having a record per-key that just appends a new tx-instant + offset for better longitudinal query performance.

Hi packetlost this is a really interesting topic to me. I wrote my MSc thesis on this exact topic - https://surrealdb.com/static/whitepaper.pdf ! I've learnt a lot since writing this thesis, and would have many different opinions if I wrote it today, but very interested in this area of research!

Same! I'll read through that paper when I have time. What are your thoughts on how you would implement something like that today?

At the time I implemented the versioning using separate trees on top of the Radix tree. Today I would augment the tree with t he versioned nodes, and would use a Concurrent Adaptive Radix Tree for the base tree. This would allow high concurrency. Then at the base of the tree I would store a temporal link to each tree modification, so that you could access the changes in time order!

Very, very interested in chatting further about this!

Same here! I'll reach out on other channels when I've compiled my notes and have a fully functioning prototype :)

Is your work public? I'm also working on a (loosely) datomic inspired database with pluggable backends, so this might be very interesting for me.

Hi the_duke. The base implementation of that key-value store (written in Golang) can be found here: https://github.com/surrealdb/rixxdb

I don't think the implementation of the ideas in the thesis were added to the public project in the end.

We will be working on this in due course in Rust, however, and the implementation will be completely open source!

I would be really interested to see / find out more about your new hybrid LSM/Extendible Hashing system!

Very cool, love the idea of JS/WASM extensions. In the past couple of years I've seen other new entries in this space - CockroachDB and Planetscale come to mind. What would you say makes SurrealDB unique, if you don't mind me asking?

Hi danielvaughn thanks so much for the comment! We love CockroachDB and Planetscale! With SurrealDB we intended to build a database where you can use the best of the relational database world, the document database world, and the graph database world. You don't have to choose up front how you store your data, but you can use many different concepts to model and analyse your data once stored.

Then with the ability to connect directly form the client application or from web browsers, you don't have to build any API layer or logic layer in front of the database. Your data access permissions and authentication sit right inside the database (only if you want of course), enabling you to build applications quickly, directly against the database.

The multi-paradigm approach sounds fantastic, I've wanted something like that for so long.

As for direct client connections - Firestore uses that approach as well. One issue with them is that your only means of security is the Firestore Rules document, which is a single script that doesn't offer much flexibility. What I've learned from using them is that if you're going to offer a direct client-to-db interface, the rules expression needs to be pretty sophisticated. Not giving advice, that's just my perspective as a potential customer. I'll take a look through your docs and will probably try it out.

Reply on news.ycombinator.com