4 ms·

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 welco

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!

mijoharas 4y ago
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.
- tobiemh 4y ago
  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!
- tobiemh 4y ago
  That's a really good note/point/addition mijoharas. We'll get it changed ASAP!
  - mijoharas 4y ago
    No worries, and no rush or anything. Was really just curious more than anything!
deleted 4y ago
[deleted]
packetlost 4y ago
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.
- tobiemh 4y ago
  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.
  - packetlost 4y ago
    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.
    - the_duke 4y ago
      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.
      - tobiemh 4y ago
        Hi the_duke. The base implementation of that key-value store (written in Golang) can be found here: https://github.com/surrealdb/rixxdb 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!
danielvaughn 4y ago
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?
- tobiemh 4y ago
  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.
  - danielvaughn 4y ago
    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.

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!

mijoharas 4y ago

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.

tobiemh 4y ago
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!
tobiemh 4y ago
That's a really good note/point/addition mijoharas. We'll get it changed ASAP!
- mijoharas 4y ago
  No worries, and no rush or anything. Was really just curious more than anything!

deleted 4y ago

[deleted]

packetlost 4y ago

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.

tobiemh 4y ago
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.
- packetlost 4y ago
  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.
  - the_duke 4y ago
    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.
    - tobiemh 4y ago
      Hi the_duke. The base implementation of that key-value store (written in Golang) can be found here: https://github.com/surrealdb/rixxdb 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!

danielvaughn 4y ago

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?

tobiemh 4y ago
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.
- danielvaughn 4y ago
  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.