upvote

points

by leafarlua9 hours ago |
comments
upvoteby yfontana4 hours ago|
next
[-]
As a data architect I dislike the term NoSQL and often recommend that my coworkers not use it in technical discussions, as it is too vague. Document, key-value and graph DBs are usually considered NoSQL, but they have fairly different use cases (and I'd argue that search DBs like Elastic / OpenSearch are in their own category as well).

To me write scaling is the main current advantage of KV and document DBs. They can generally do schema evolution fairly easily, but nowadays so can many SQL DBs, with semi-structured column types. Also, you need to keep in mind that KV and document DBs are (mostly) non-relational. The more relational your data, the less likely you are to actually benefit from using those DBs over a relational, SQL DB.

reply
upvoteby marcosdumay8 hours ago|
prev|
next
[-]
NoSQL was created to deal with scales where ACID becomes a bottleneck. It also shown itself useful for dealing with data that don't actually have an schema.

If you have either of those problems, you will know it very clearly.

Also, ironically, Postgres became one of the most scalable NoSQL bases out there, and one of the most flexible to use unstructured data too.

reply
upvoteby freedomben8 hours ago|
parent|
[-]
Agreed. In my experience (YMMV), there was also a real adoption push in the js world from primarily front-end people that wanted to do some backend but didn't want to learn/deal with SQL databases. I don't say that with malice, I was also on-board the NoSQL train for a bit before I actually gained experience with the headaches it caused. The appeal of "just dump your JSON blob straight in" was (and still is) strong. Software is all about learning, and sometimes that learning is expensive. We've all built something we later regretted.
reply
upvoteby gf0007 hours ago|
prev|
[-]
Probably the best use case would be something like a Facebook profile page for a given user.

It may not have a very rigid schema, you may later add several other optional fields.

You need very large scale (as in no of concurrent accesses), you want to shard the data by e.g. location. But also, the data is not "critical", your highschool not being visible temporarily for certain users is not an issue.

You mostly use the whole dataset "at the same time", you don't do a lot of WHERE, JOIN on some nested value.

In every other case I would rather reach for postgres with a JSONB column.

reply