This is the same trick as the rest of Deno KV: the open source version uses SQLite, but when you deploy to their cloud product you get Foundation DB (proprietary) instead:
> Since Queues are built on Deno KV, it uses SQLite when running locally and FoundationDB when running on Deno Deploy for maximum availability and throughput.
Just as an side note, not relevant to anything in particular, Foundation DB itself is open-source (https://www.foundationdb.org/), but the integration layer used by Deno to make it the backend for Deno KV is not.
Although, from reading the Foundation DB docs and checking the Deno KV API, I honestly suspect it is a thin layer.
Self-hosting FDB is somewhat inscrutable though, so their value add is in not having to handle infrastructure while being backed by FDB.
Partly it's about building habits around them. I watch out for any time I have to spend half an hour or more figuring something out - that's generally a sign that it's worth tidying up my notes into a TIL, since the internet is clearly missing that piece of information!
I keep very detailed notes on everything I'm doing already - either as a VS Code scratch document or Apple Notes or often a GitHub Issues thread. A lot of my TILs start by me pasting those notes into a Markdown file and tidying them up.
> Since Queues are built on Deno KV, it uses SQLite when running locally and FoundationDB when running on Deno Deploy for maximum availability and throughput.
I wrote a bit more about this pattern here: https://til.simonwillison.net/deno/deno-kv