no thanks. i'd much rather trust postgres to handle things like foreign keys, unique constraints, transactions, and other goodies than the application, which is is what ends up happening when you try to do this in a key:value store.

> Often times, we end up spending countless hours setting up databases, schemas, and dealing with ORM systems, where we could simply treat data as keys and values.

There is always a schema, whether you want your database to help you with it or not is your choice.

Ouch, this smells like a 2019 reenactment of the MongoDB disaster that rightfully burned a generation of Devs and Ops.

I‘ll leave this here for posterity:

https://www.vividcortex.com/blog/2015/02/24/schemaless-datab...

— Schemaless Databases Don‘t Exist

SQL is not that hard. And the very slight amount of analytical rigor needed to atomize data, normalize data, and think about relationships between data, makes you smarter, gives you many more options for slicing & dicing the data, and if you have a a proper RDMS, it runs faster'n shit. Parsing/serializing/deserializing JSON blobs, not so much.

Christ - what is with these Benjamin Button development fads? Dealing with the NoSQL silliness of the last few years was bad enough, but just wait until the next generation of devs discovers storing shit in flat files on the local filesystem...

Ok, we all know how a key-value store is not competitive with the current SQL db's. But lets remember all of this NOSQL trend started with the SQL databases being a poor fit for a distributed environment back in the day.

By the way, what i would actually love to have, is a LINQ like API abstracted over a key-value store, and access to a SQL AST also in the language.. For me i think this is the desired middle ground, where you can scale and compose data over key-value, but also not to be stuck with SQL data mappings inside your codebase.

I mean, a relational algebra API that deal with any KV store, be it LINQ or the backend of something like Presto (or the DataFrame of Spark).

If you need something like a SQL interface somewhere, you could build it by stitching the SQL AST with the engine you use directly in the language.

uch... what a headache when a user needs to change their email. The mania for "schema-less" KV stores is so puzzling to me. It just takes all the stuff that used to be handled natively and seamlessly by the DB engine and forces you to reimplement it in code, only with more bugs, less efficiency, and less flexibility. I fought this battle on my current team and lost, and we have been paying a steep price ever since.

The OP's last 4 submissions have all be promoting this kvdb.io service.

So, I heard that Amazon developed Dynamo because they realized that most of their table lookups were either:

* looking up an item by a key

* selecting a range of items

I would never choose a key-value DB for "scalability" reasons. It's very unlikely that I will be hitting the kind of scale where it would actually make a difference.

Where I have found it useful in my particular line of work is in a fairly narrow context: working in a microservice architecture where you create a single service between your system and a 3rd party system, and it's database is essentially a mapping of your own system's IDs to the ID's of the 3rd party.

Honestly, that plus one or two secondary indexes is all I've really needed. I've done that for 3 different integrations over the course of 2 years now, and it's worked out quite well so far. The fact that we have a strict policy of not sharing db access also means that I'm not to worried about other services trying to query the data in weird ways.

There are of course more fancy patterns for structuring your data in a key-value store, but at that point the main benefit of kv stores starts to diminish once you go down that path.

alternate title: "Ditch your decades-old, stable technology that everybody in the industry knows for our product that makes absolutely no case for use beyond a basic user query."

I agree that dynamism can be helpful for prototyping and rush-job applications, but I'd rather "dynamic relational" be implemented for such: https://stackoverflow.com/questions/66385/dynamic-database-s... One can gradually add constraints to give it RDBMS-like strictness as the project matures. And you can use SQL on it, with minor modifications to assist in comparing dynamic (implied) types.