DenoSyntheticKV

I support the effort but there are a few issues with this implementation:

1. constructors are always synchronous so you need to keep around the handle to deferred table initialization (https://www.val.town/v/stevekrouse/DenoSyntheticKV#L8)
2. serializing keys with superjson turns strings into objects (e.g. "foo" becomes {"json":"foo"}) which makes interoperability with existing solutions almost impossible: @vladimyr/kv_example

Point (1) is an excellent one! I guess that's why they do it as openKV in their implementation

For point (2), I went in this direction because I was more concerned with getting code that uses Deno KV to work (@stevekrouse/passkeys_demo) than I was with anything else, and they store some pretty funky objects in KV storage in that example!

I wonder how hard it would be to create a deno kv backend built on top of std/sqlite. There is one example here: https://github.com/denoland/denokv

You mean translate the actual KV Connect network protocol to a bunch of @std/sqlite API calls?

Well here is the documentation: https://github.com/denoland/denokv/blob/main/proto/kv-connect.md#protocol CRUD stuff requires ProtoBuf while @std/sqlite works with JSON. I'm wondering about the potential performance penalty incurred by marshalling cost 🤔

You mean translate the actual KV Connect network protocol to a bunch of @std/sqlite API calls?

Exactly. But I forgot the whole backend was implemented in rust, this might be trickier than I expected.