It's Time to Stop Building KV Databases

#1

Post by foldU » Mon, Mar 24, 2025, 8:31 PM UTC

It's Time to Stop Building KV Databases
buttondown.com

Re: It's Time to Stop Building KV Databases

#2

Post by tyzoid » Tue, Mar 25, 2025, 1:16 AM UTC

Sometimes a KV datastore is the right abstraction, though. Caching is an excellent example, but also for distributed session storage, configuration management, nonce enforcement, etc.

Re: It's Time to Stop Building KV Databases

#3

Post by fud101 » Tue, Mar 25, 2025, 2:27 AM UTC

Is this a good take? I'm just a below average dev and trying to figure it out.

Re: It's Time to Stop Building KV Databases

#4

Post by esafak » Tue, Mar 25, 2025, 2:35 AM UTC

tyzoid wrote: post #2

Sometimes a KV datastore is the right abstraction, though. Caching is an excellent example, but also for distributed session storage, configuration management, nonce enforcement, etc.

KV stores can be used to build distributed relational databases.

Re: It's Time to Stop Building KV Databases

#5

Post by treyd » Tue, Mar 25, 2025, 2:41 AM UTC

fud101 wrote: post #3

Is this a good take? I'm just a below average dev and trying to figure it out.

Like most articles that make strong assertive statements like this, it's an oversimplification. Every tool has its place. The author clearly wants to use SQL, and seems to have a problem that would benefit from it, so they should use a SQL DB and not try to use a KV DB.

Re: It's Time to Stop Building KV Databases

#6

Post by foldU » Tue, Mar 25, 2025, 2:43 AM UTC

fud101 wrote: post #3

Is this a good take? I'm just a below average dev and trying to figure it out.

Yes, it’s good

Re: It's Time to Stop Building KV Databases

#7

Post by technick » Tue, Mar 25, 2025, 2:46 AM UTC

fud101 wrote: post #3

Is this a good take? I'm just a below average dev and trying to figure it out.

Very opinionated clickbait if you ask me.

Re: It's Time to Stop Building KV Databases

#8

Post by Spivak » Tue, Mar 25, 2025, 2:47 AM UTC

Finally! Someone else reaching the conclusion that the query planner is really annoying and for most queries I would just like to skip it.

I don't want the dynamic nature of the planner. I don't want to send SQL over the wire, I want to send the already completed plan that I either generated or wrote by hand. So many annoying performance bugs are because the planner did the slow thing. Just let me write/adjust it.

Re: It's Time to Stop Building KV Databases

#9

Post by lmm » Tue, Mar 25, 2025, 2:48 AM UTC

fud101 wrote: post #3

Is this a good take? I'm just a below average dev and trying to figure it out.

Is he right that this imaginary future product might be a better solution than current KV datastores? Maybe - he makes a good case, it certainly sounds worth pursuing, and he can point to a case where it sort of works well already (FoundationDB).

Doen that imply that you should give up on KV datastores today, when this product category he's asking for barely exists? No, obviously not.

Re: It's Time to Stop Building KV Databases

#10

Post by mjevans » Tue, Mar 25, 2025, 2:49 AM UTC

K:V - maps / dictionaries can be the correct tool for some jobs.

I think I'd prefer to stop calling _large_ resources that are only K:V a 'database' though.

A 'database' shouldn't require SQL, but a distributed filesystem, however similar, isn't quite a database.