That's a really good point and honestly a very reasonable feature for a minimal store. TinyKV stores keys in a HashMap internally, so it doesn't currently support lexicographic ordering or prefix scanning efficiently. But you're absolutely right if we switched to a BTreeMap (or exposed one as an option), prefix queries could be both fast and natural. I'll add this to the roadmap. Would you mind opening a GitHub issue with your specific use case?

Great question! tinykv isn't trying to replace SQLite – they serve different needs. SQLite strengths: relational queries, ACID transactions, SQL. Complex data relationships and multi-user concurrent access. tinykv strengths: zero setup (no schema, no SQL), human-readable files (JSON – you can git diff them!), simple key-value API, built-in TTL support, Serde integration (any Rust type → storage).

Use cases where tinykv fits better: CLI tool config storage, game save files, application preferences, prototyping/MVP development, when you want to inspect/edit the data file manually.

I built it because I kept reaching for simple persistence, but SQLite felt like overkill for storing a HashMap<String, Value>.

Exactly! Python's dbm is a great comparison. tinykv aims for similar simplicity but with some Rust-specific advantages. The key difference is dbm gives you flexibility in storage format, tinykv gives you zero-ceremony type safety + readability. If you want the Python dbm experience in Rust with modern ergonomics, that's basically tinykv's sweet spot.

Both solve the "I just need simple persistence" problem, tinykv just does it the "Rust way" with strong typing and serde.