Best storage engine for mobile

[dr-orlovsky]

With the move from running multi-threaded RGB Node on mobile towards using a small RGB standard library wrapped into C FFI we have an opportunity in the future versions to use more efficient data storage than it is used today (raw files + sled).

What would be your choice for the best mobile storage backend for:

1. stash data (blob db)
2. different indexes (key-value db)
3. contract state cache (think of it as of JSON - or BSON documents)

My criteria would be:

• it should be native rust
• optimally WASM compiled
• no-std support

I believe the criteria above can't be achieved, so we will need to sacrifice something...

[cryptoquick]

I prefer a flat-file blob db, since it's the simplest and most versatile. If speed is needed, an index can be kept in memory. Records in the flat file could fold into a key-value schemaless datastructure.

[dr-orlovsky]

You mean custom one?

And what about pt 2. - fast indexing based on btries? The index may be large and for a library it would be significant slow down to read it each time into the memory.

Interesting which storage format is used for git for indexes

[cryptoquick]

It depends on what's put in the index; is a 10MB index for 1GB worth of consignments worth the complexity of a database?
Another alternative is to use device-native databases, similar to how browsers have localstorage.

[dr-orlovsky]

I am not looking for a database, just a good crate doing the embedded "database" is fine (sqlite for instance is not a database, but it is a C lib which is undesirable)

[cryptoquick]

Hm. A good alternative to sled is redb, it's used by the ordinals project:
https://github.com/cberner/redb

[dr-orlovsky]

What advantages have redb over sled? I see it has better performance, right? Any other?

[zoedberg]

I'm still having a hard time understanding why we need this and especially how it's meant to be implemented.

From https://github.com/orgs/RGB-WG/discussions/238#discussioncomment-4708892 I've understood that most of rgb-node code will go to rgb-std and that storage will not change (we'll keep sled) so no migration will be needed.

But from what you're saying here it seems that you want to avoid using sled on mobile, so are you planning to make rgb-std more abstract in a way that it can handle different storage systems?