I poked around with this a few months ago to figure out how it works locally. The answer is SQLite: <a href="https://til.simonwillison.net/deno/deno-kv" rel="nofollow noreferrer">https://til.simonwillison.net/deno/deno-kv</a><p>I'm finding the business model aspect of Deno KV absolutely fascinating.<p><pre><code> const kv = await Deno.openKv();
</code></pre>
That's a Deno core API. It works fine in the open source version of Deno using a local SQLite database file.<p>But as soon as you deploy your application to their proprietary hosted service, that core API feature gets massively more powerful. It's no longer a SQLite database, it's now a globally distributed key/value store backed by FoundationDB, replicated around the world.<p>It looks like they've extended that idea further with the latest version - you can now do this:<p><pre><code> export DENO_KV_ACCESS_TOKEN="personal access token"
const kv = await Deno.openKv(
"https://api.deno.com/databases/your-database/connect",
);
</code></pre>
And your local code is now able to manipulate that remote FoundationDB database as well.<p>I'm having trouble thinking of a precedent for this - an open source project that has a core API which is effectively a lead generator for their proprietary cloud service.<p>I'm not entirely sure how I feel about it. I think I like it: open source projects need a business model, and the openKv() method is still a supported, useful part of the open source offering.<p>Kind of fascinating pattern though.<p>UPDATE: I just found this page of docs <a href="https://github.com/denoland/deno/blob/be1fc754a14683bf640b7bf0ecf6e286d02ee118/ext/kv/README.md">https://github.com/denoland/deno/blob/be1fc754a14683bf640b7b...</a> - which describes the "KV Connect" protocol they are using. It looks like this evens the playing field, in that anyone could implement their own alternative backend to Deno Deploy if they wanted to.<p>This firmly establishes me on the "I think this is cool" side of the fence.