They probably do use lots of NoSQL DBs too, which perform better for non relational "data lake" style architectures where you just wanna dump mountains of data as fast as possible into storage, to be perused later.

When you have cases where you have very very high volume of data in, but very low need to query it (but some potential need, just very low), nosql DBs excel

Stuff like census data where you just gotta legally store it for historical reasons, and very rarely some person will wanna query it for a study or something.

Keep in mind when I talk about low need to query, the opposite high need us on the scale of like, "this db gets queried multiple times per minute'

Stuff like... logins to a website, data that gets queried many times per minute or even second, then sometimes nosql DBs fall off.

Depends what is queried.

Super basic "lookup by ID" Stuff that operates as just a big ole KeyValuePair mapping ID -> Value? And thats all you gotta query?

NoSql is still the right tool for the job.

The moment any kind of JOIN enters the discussion though, chances are you actually wanna use sql now

[–] Thorry84@feddit.nl 28 points 2 days ago (3 children)

So you're saying Relational DataBase Management Systems do really well as soon as Relations are involved?

[–] yopp@infosec.pub 2 points 2 days ago

What’s funny is that Relational Databases in fact sucks when somewhat complex Relations are involved. Moment you step out the of the realm of Tabular data you’ll have very miserable time. Like good luck modeling and querying simple nested product catalog.

Graph databases are better choice for truly relational data

load more comments (2 replies)

load more comments (7 replies)

load more comments (12 replies)