Funny you should ask. I have been building a DO-based app of my own (to organize LAN parties...), an
Funny you should ask. I have been building a DO-based app of my own (to organize LAN parties...), and I actually decided I was happier with KV rather than SQL because I liked the ergonomics of just shoving whole JS objects into storage. It's a legitimate choice.
That said, as Larry points out, one big thing you'll lose that way is secondary indexes. In my case I had to hand-roll one or two secondary indexes, which was a bit of a pain.
Also note that even if you are using the KV API, you are still getting most of the benefits described in the blog post, since we're actually storing your KV data in SQLite under the hood. It's a bit harder to reason about sync/async though -- the KV interface appears to be async, but it's actually effectively synchronous when backed by SQLite.
That said, as Larry points out, one big thing you'll lose that way is secondary indexes. In my case I had to hand-roll one or two secondary indexes, which was a bit of a pain.
Also note that even if you are using the KV API, you are still getting most of the benefits described in the blog post, since we're actually storing your KV data in SQLite under the hood. It's a bit harder to reason about sync/async though -- the KV interface appears to be async, but it's actually effectively synchronous when backed by SQLite.