You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is a significant time investment (and we don't want to maintain a fork of Deno) so we are at a crossroads where it would help to know Deno team's opinion on this before we proceed. Would you be interested in having LMDB as an optional backend to Deno.Kv, built directly into Deno?
We were thinking users could supply a URI like await Deno.openKv('lmdb://mydb.db') to select the LMDB backend. It would work seamlessly with the existing Deno.Kv API and provide a high-peformance option. SQLite would continue working with a bare path.
So, then we started exploring the Rust side, and realized Deno.Kv is already very modular in the Deno codebase, and we began exploring that with denokv_lmdb.
We have been struggling with 30GB+ SQLite files in our application. Meanwhile LMDB is very fast in our tests. Here's a very simple benchmark of the difference:
It seems to me like Deno.KV and LMDB are a perfect match for running self-hosted instances. The author of lmdb-js even described Deno.Kv as "straightforward" with "pretty direct mappings". It wants to exist.
But the question is - if we build you a perfect LMDB backend for Deno.Kv, up to your code standards, do you want to merge it? Depending on this answer, we will either keep chipping away or switch to some sort of FFI implementation.
Thank you for your consideration!
The text was updated successfully, but these errors were encountered:
For now, we'd be pretty unlikely to merge this, as we already have SQLite in the Deno binary, and adding LMDB just for this would quite significantly increase our binary size.
Hi all!
I have been working with @xyzshantaram (see his comment here) to add LMDB support directly into Deno, as an optional backend to Deno.KV.
We started writing
denokv_lmdb
in Rust: https://github.com/xyzshantaram/denokv_lmdb But we would like to know if this is something the Deno team would consider merging if we complete it?It is a significant time investment (and we don't want to maintain a fork of Deno) so we are at a crossroads where it would help to know Deno team's opinion on this before we proceed. Would you be interested in having LMDB as an optional backend to Deno.Kv, built directly into Deno?
We were thinking users could supply a URI like
await Deno.openKv('lmdb://mydb.db')
to select the LMDB backend. It would work seamlessly with the existing Deno.Kv API and provide a high-peformance option. SQLite would continue working with a bare path.We explored other options first, like just using lmdb-js (@kriszyp) directly. I even started building a lmdb-js to Deno.Kv adapter in TypeScript. But unfortunately lmdb-js on Deno is a nonstarter due to unimplemented Node APIs.
So, then we started exploring the Rust side, and realized Deno.Kv is already very modular in the Deno codebase, and we began exploring that with denokv_lmdb.
We have been struggling with 30GB+ SQLite files in our application. Meanwhile LMDB is very fast in our tests. Here's a very simple benchmark of the difference:
It seems to me like Deno.KV and LMDB are a perfect match for running self-hosted instances. The author of lmdb-js even described Deno.Kv as "straightforward" with "pretty direct mappings". It wants to exist.
But the question is - if we build you a perfect LMDB backend for Deno.Kv, up to your code standards, do you want to merge it? Depending on this answer, we will either keep chipping away or switch to some sort of FFI implementation.
Thank you for your consideration!
The text was updated successfully, but these errors were encountered: