Deno KV adapter

[alexgleason]

Deno KV is awesome: https://deno.com/[email protected]/runtime/kv

Deno now ships with a built-in zero-configuration database. When deployed to their proprietary hosting service, it's backed by FoundationDB. However, when self-hosting it's backed by SQLite. I only care about self-hosing, so I know the performance will only be as good as SQLite.

If only it were backed by LMDB, the performance would be great, and it would work with awesome Deno KV projects like Pentagon: https://github.com/skoshx/pentagon

People are building stuff the Deno.Kv API. I wonder if we can adapt lmdb-js to the Deno KV API.

[kriszyp]

I think this a great idea. I don't think I currently have the bandwidth to do this, but it seems like it would be a great project. And actually it seems pretty straightforward; most of the Deno KV operations have pretty direct mappings lmdb-js (lmdb-js even supports keys as sequences of primitives). I would be happy to try to provide any necessary primitives for this though, although again, it would seem that lmdb-js provides everything that is needed (there might be some optimizations that could be done to support a native sum/min/max operation, but they can definitely be done atomically with lmdb-js's transactions).

[alexgleason]

This is great news. I will likely have to build it at a certain point if my project grows how I hope it will. But I have a lot to learn about LMDB first.

[kriszyp]

I know you ran into issues with the unimplemented NAPI apis and went with a Rust implementation per denoland/deno#23545, but I am curious why asyncTransaction callbacks are really needed for a KV store? I would think lmdb-js should be able to handle everything that DenoKV does, and certainly has vastly faster (write) performance than what you reported in the deno ticket (lmdb-js can is achieve 100x faster write throughput, with batching, than that).