tobiemh

7 ms·

31.
by tobiemh 4y ago
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 di
32.
by tobiemh 4y ago
Hi mackeyja92 great suggestion! We're not big Erlang/Elixir users, but we definitely want to integrate with Elixir and LiveView in due course! We actually received a suggestion to do this just yesterday! We would love to hear any
33.
by tobiemh 4y ago
Hi hiyer! We've got a single-node storage implementation using RocksDB coming this week. With regards to running in distributed mode, TiKV (and soon FoundationDB) will be able to be used for storage. In the long run we would like to bu
34.
by tobiemh 4y ago
Hi phailhaus, good point. We don't want to go for speed (for instance by writing to /dev/null) at any cost, but want SurrealDB to be a reliable and performant backend for any application in the long run. Obviously in our opin
35.
by tobiemh 4y ago
Hi Diggsey, great question. We are currently focussed on functionality and stability, and then will draw our attention to performance. Coming this week we have a RocksDB storage implementation. We've only just launched our initial beta
36.
by tobiemh 4y ago
Absolutely mackeyja92. We were users of RethinkDB back in the day. We wanted to bring the best features/functionality of NoSQL databases (MongoDB/RethinkDB/CouchDB/...), graph databases (Neo4j/OrientDB/...), an
37.
by tobiemh 4y ago
I would be really interested to see / find out more about your new hybrid LSM/Extendible Hashing system!
38.
by 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
39.
by tobiemh 4y ago
Hi jxi thanks for the question! Our plan is to make SurreealDB accessible and usable from as many codebases/platforms/architectures as possible. We've got plans for integration into all of the big IDEs down the line, so we ab
40.
by tobiemh 4y ago
That's a really good note/point/addition mijoharas. We'll get it changed ASAP!
41.
by tobiemh 4y ago
Absolutely debuggerpk. My answer to arunc above goes into it in slight detail! We will definitely plan to do an in-depth look at the decision to transfer from Golang to Rust in a future blog post!
42.
by tobiemh 4y ago
Absolutely arunc! You can actually see the Golang version - it's on a separate branch in the main repository. We had written our query parser from scratch (which would read character by character). This worked well, up to a point, but
43.
by 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 remov
44.
by tobiemh 4y ago
Hi dmytrish that's exactly it! We are really close to releasing our WebAssembly driver (built in Rust), a native Python driver which can connect to and embed SurrealDB (built in Rust), and a native Node.js driver which has the same fun
45.
by tobiemh 4y ago
Hi techn00! It's definitely taken a while for us to get to this point. We initially starting planning to build SurrealDB back in 2016, and started building on top of our initial database prototype (built in Golang) back in 2018. Over t
46.
by tobiemh 4y ago
Hi RayVR, being built in Rust definitely isn't a main selling point, but it has made building SurrealDB easier. We initially built our prototype in Golang, but decided to re-write it in Rust so that we could improve on certain aspects
47.
by tobiemh 4y ago
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!