I'm finding the business model aspect of Deno KV absolutely fascinating.
const kv = await Deno.openKv();
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.
It looks like they've extended that idea further with the latest version - you can now do this:
export DENO_KV_ACCESS_TOKEN="personal access token"
const kv = await Deno.openKv(
"https://api.deno.com/databases/your-database/connect",
);
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.
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.
Kind of fascinating pattern though.
UPDATE: I just found this page of docs https://github.com/denoland/deno/blob/be1fc754a14683bf640b7b... - 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.
This firmly establishes me on the "I think this is cool" side of the fence.
It has been happening for a while with a bunch of startups like Supabase claiming to be "open source" and marketing themselves as such but making it really hard to self host for a long time.
It wasn't just them either.
I would see with disgust a bunch of startups use "open source" as their marketing tactic, no matter how hard it was to setup or run without their hosted service.
It is also a peverse incentive: the harder the open source system is to run and maintain, the more you will gravitate toward their cloud. Supposedly open source companies raising a ton of money from VC is also strangely contrary to the open source ethos.
Deno KV is basically the next jump in that chain.
Richard Stallman was right once again, as usual.
You can simply not use it, no?
I am not going to make any sweeping generalizations across all products. But at least in the case of Deno KV, there doesn't seem to be lock-in. So if you were running something self-hosted for KV persistence, it will continue to work unmodified.
> I would see with disgust a bunch of startups use "open source" as their marketing tactic.
Again, not sure which bunch of startups. But I am not seeing that with this product. Seems more like a survival strategy to add some cashflow behind the developers.
I am curious what you think Open Source should be (or should not be). I think it's fair that running a service in the cloud should cost something. And self-hosting it, I think it's fair that it requires a bit more effort than using the hosted service.
It looks to me like they've documented the KV Connect protocol they invented to support this feature, in enough detail that anyone else could build an alternative backend for it.
This has helped me feel completely OK with how they're handling this. They get an advantage in that they've already built an extremely robust proprietary backend, but I find that acceptable given the documented protocol.
I'm really confused by this statement. What exactly is being degraded in their service? Or in their API? Or in the underlying tech they are compatible with?
All I see here is an open source system that you can manage and deploy yourself, with a 100% compatible API for a cloud service that handles that for you, should you decide to pay money to have that problem solved for you.
I find your comment to be quite dramatic.
I'm building a back end with Deno and MariaDB, and pretty psyched about it so far. I haven't built a back end since I did one with PHP 5 in 2011 or so. Thus far I've found it easier to get something working than I did with the tools years ago. So much so that I'd consider throwing these guys a bone by paying for a service.
But... I don't know that a key/value store suffices for what I want to do, which will involve relational queries.
Don't expect Deno or any other corporate entity solely focused on profit seeking to give a single shit about anything other than profit.
It's all marketing, it's all spin, and it can't be any other way, that's how the system is structured.
Cloudflare’s pricing seems more reasonable, though a 1:1 comparison is impossible. Cloudflare reads and writes in every region for the same price, Deno scales price with number of replica regions. Also CF is billed per read/write operation (and supports listing), this is billed per kB read/written.
That all said, if your values are bigger than ~2kB Cloudflare is almost certainly cheaper. And the list (with metadata) operation is quite powerful.
However, single-region means you don’t have to care about synchronization nearly as much, which can be quite annoying. The end user experience will suffer in areas far from your write zone though.
A better comparison might actually be Cloudflare D1, a hosted SQL with per-kB fees, but that’s still beta.
Is this not Vercel’s entire business model? I don’t think they invented it either.
By the time you've implemented even a basic key-value store with on-disk storage you've probably written a bunch of code that would be unnecessary if you had used SQLite.
People choose NoSQL databases primarily for scaling reasons, which is not the problem here.
I find the way they handle secondary indexes very interesting. I mean under the hood I think DynamoDB does pretty much the same thing (stores the data multiple times) but instead of explicitly writing the data multiple times you define fields on the data that the secondary indexes use so the data is written there at the same time it's written to the primary (I could be a little mistaken, I'm working at a higher abstraction layer so I don't think about that). I can't decide which approach I like more. I will say that I don't think I'd need anything but my own abstraction layer to work with Deno KV vs DynamoDB. That said I still think DynamoDB is way more powerful overall.
As always I'm rooting for Deno to succeed.
[1]: https://github.com/denoland/deno/blob/be1fc754a14683bf640b7b...
Deno KV - https://news.ycombinator.com/item?id=35743446 - April 2023 (11 comments)
What have been the biggest pros? The biggest cons? Would you use it again (one alternative could have been TikV).
> import { Semaphore } from "https://deno.land/x/semaphore@v1.1.2/semaphore.ts";
Should just be~
> import { Semaphore } from "deno/utils";
Or something like that.
idk i just think there's many options besides a full url in your code