tikv VS redis-rs

I know that very similar functionality to this is in TiDB Serverless ( https://tidbcloud.com ). TiDB is a distributed relational database. It uses TiKV ( which is a key/value engine ) as the storage engine. You could use SQL to access your K/V records. There is ongoing work in TiKV to support S3 directly as the storage backend ( https://github.com/tikv/tikv/issues/6506 ) .

TiKV is basically a layer on top of rocksdb https://github.com/tikv/tikv/blob/956610725039835557e7516828...

> Many,many smart people…

If you look inside the code you can see the stated features are a result of underlying engine (TiKV [0] also 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.

[0] https://tikv.org/

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 version, and we know there is a lot of improvement and work to be done (some of these performance issues we know about already and are on our Github issues list).

With regards to the consistency/isolation model, SurrealDB sits on top of a number of key-value stores. By using the distributed highly-available TiKV storage backend, https://tikv.org, (and we have a FoundationDB integration in the works), the database is designed to be highly-scalable and highly-available. The same guarantees (albeit just single-node, so no high-availability or scalability) will be available with the RocksDB implementation coming this week. By sitting on top of these key-value stores, SurrealDB ensures that all transactions are ACID compliant. We don't want to go for speed (for instance by writing to /dev/null) over anything, but want SurrealDB to be a reliable and performant backend for any application. Obviously we have a way to go to catch up with PostgreSQL (launched in 1996), but we will strive to get there!

If you are looking for a production ready distributed store written in Rust. Check out TiKV(https://github.com/tikv/tikv), which was also mentioned in the acknowledge section of the project's README.

There's also a full-featured distributed RDBMS called TiDB built on top of TiKV.

The goto Redis client for Rust is called redis-rs. It has over 3k stars on Github. but I found it very annoying to use because I quickly found out that if you want to set any value you had to get a mutable reference to the underlying client. Which meant great pain to store Redis client in the global scope. People who do not know what a mutable reference is consider the let keyword in JavaScript. you can mutate or change a variable that is initiated with let.

staticpi, is a websocket forwarding service. Basically, it enables one to keep a Raspberry pi, or any computer, “connected”, in order to send and receive messages to and from any client, without having to deal with a static IP address, open ports on your router, or similar. Built in Rust, using axum, which in turn uses tungestine-rs for the websocket connections, tokio, sqlx, redis-rs and others.

redis (use streams and pubsub)

Are you addressing the long-standing issue that the redis client has related to dropped connections?

I switched to LALRPOP for gluon but I still use combine in https://github.com/mitsuhiko/redis-rs and some other projects which need to parse "protocols" (less need for good error messages/error recovery and more need for speed).

The project is implemented with MongoDB Rust driver and redis-rs crate.

redis-rs, a Rust library for Redis with both high and low-level APIs

I think the redis crate was a well-organized API library. It's still sometimes hard to know the right things to make public and I think they nailed it.

We have been using it before it got merged in redis-rs (we upvoted the PR here https://github.com/mitsuhiko/redis-rs/pull/319 a while back ;-))