this post was submitted on 01 Dec 2021
7 points (100.0% liked)

Rust Programming

8156 readers
8 users here now

founded 5 years ago
MODERATORS
 

I'm looking for suggestions for an in-memory database or other type of store that syncs to the file system (preferably as a single file) to store small, text-only documents (notes) and additional metadata.

It should preferably be made purely with Rust and have no dependencies to outside libraries like SQLite (without the dependency to the sqlite library in the system it would be my first choice). Also it shouldn't depend on any server/service running in the system.

It should support relational data (but not necessarily relational as in SQL and relational databases) to allow fast and easy searching and retrieval of data.

So far I (from the crate descriptions only) I found RedDB. the rql crate looks promising, too, even though I'll have to write the sync to the filesystem myself.

Are there more suggestions?

you are viewing a single comment's thread
view the rest of the comments
[–] dessalines@lemmy.ml 7 points 2 years ago* (last edited 2 years ago) (7 children)

I'm not a big fan of memory-only stores, but I believe sled is entirely in memory. @asonix@lemmy.ml is that correct? Its key-value, so not SQL-like, so maybe not the best for your use case.

I do really recommend using sqlite, or if its server-based, postgres. These aren't written in rust obvi but they have great performance, and there are plenty of rust libraries to talk to them.

Also if your use case is storing text-documents, I def would not use a memory store.

[–] vvv@lemmy.ml 2 points 2 years ago (1 children)

I definitely don't want a database that needs to be installed first as I want to write a tool that can be thrown at a user and is instantly usable. So PostgreSQL and similar DBs are not an option. My problem with SQLite is, that it's not available everywhere, so I'd have to ship it with my app which again leads to a more complex setup. I'll have a look at sled, though, thanks!

load more comments (5 replies)