What are your use cases for noSql dbs? I haven't really found a reason beyond stuff like chat messages or logs, but even those tend to work perfectly fine with SQL.

I imagine they're pretty good for prototyping, but haven't really tried them out for that yet. Perhaps for cases where you're handling billions of records?

Big json dumps, reports, etc. Key-value stuff. I'm about to implement a repository to fetch some reports, structurized [jsonized] parsed and cached data for further processing, etc - things I can associate to a single key.

For event-based serveless cloud native architectures they are pretty useful, when each domain service rules their own data. Relational data models may in many cases not be optimal solutions.

Depends on the use case.
Sql - if requires data retrival by a random field.
NoSql - data retrival by the key only.

One of the projects I'm working on deals with highly nested data. An array of maps of arrays of maps... I struggled for a day or two to design a SQL database schema that would actually work without being horrendously complicated before I gave up on that and used mongodb instead.

@magicMirror MongoDB is pretty good at querying too though as it’s not key-value based.

Besides everything people already wrote here, REDIS is awesome for handling state of many-actor interactions. I.E. monitoring IoT devices and CRM interactions.

I'd be so happy if the term NoSQL would finally be forbidden from ever used again....

NoSQL has no meaning. It's plain stupid.

Even more as many document oriented databases _added_ SQL support.

What makes it even worse is asking why <forbidden word> should be used...

What are we talking? Key Value? Document oriented? Columnar?

It's making me angry as there are _huge_ differences between them.

A lot of the why and what boils down to the CAP theorem, what exactly you try to achieve and what problem you want to solve.

E.g. a document oriented database that isn't focused on being consistent wouldn't be a great idea for archiving important data - ACID of SQL databases would be definitely your choice.

Not needing tuples of data like in SQL or a document, but instead key value? Key Value storage is the way to go.

Need to sift through tons of documents, but combined with consistency? Choose a document oriented database which focuses on consistency, preferably with an inverted index and append only behaviour to gain "Brrrrr speed".

Needing to mass update data regularly? Document oriented with an inverted index would be a pain in the ass. Every update would be a soft delete in the index, adding new index data in eg a segment (Lucene) or similar storage and you would have on hell of a nut job of getting this to work with scaling... Tuple based database systems could handle this better.

TLDR: NoSQL is the shittiest term. Forget it and think about what actual type of database storage / system you mean.

@TrevorTheRat
I don't actually care about the specifics. Yes - you can store key/value in sql. Yes - you can use nosql for tables and complicated queries.

But whyyyyyyyy would you do that? Do you use a hammer for screws, and screwdriver for nails? just becuase you can?

@magicMirror
Is far as I know there isn’t anything you can do in one that you can’t do with another. It’s just how easy it is.

Relational tends to be better for running reports off and everyone knows what sql. Having a schema means some reporting apps can linked to the db and provide power adhoc reporting.

Personally I prefer Mongo because I write repos that return an aggregate, and that closely represents what Mongo calls a document. I can refactor as much as I want without having to touch a database schema.

But some devs prefer a database schema because even though it’s more hassle it’s also validation that your existing data isn’t broken and it forces you to do something about it.

Another example would be DynamoDb is serverless and designed for scalability so you would choose that if you’ve got some fairly simple access patterns and want zero db server maintenance. But you have to deal with figuring out how much it would cost and if you’re happy with it