Explain NoSQL Databases Like I'm Five

Hello dev!

I'm having a hard time trying to understand NoSQL Databases. Can someone tell me what advantages and disadvantages has when compared to Relational databases? When would you choose for example MongoDB instead of SQLServer? Is it worth studying them for my career?

Comments

[Andrew (he/him)]

You can think of a regular SQL database as a list of vectors. In an SQL database, each vector must have the same length and carry the same kind of data at the n-th index:

[ // the database itself is a "list of vectors"
  ["string", false, 3.14] // each row is a fixed-length "vector"
  ["another", true, 2.781828] // values at a given "column" must all have the same meaning
]

In a NoSQL database, no such rules apply. Rows can have any number of elements and hold any kind of data. This means that "column headers" will be different for each row, as well. Note that this is a general rule of thumb for NoSQL databases, but there are many different kinds of data storage mechanisms for NoSQL.

In general, NoSQL is more flexible than SQL and the particular "flavor" of NoSQL database that you need is dependent on the constraints of your problem. NoSQL can be faster than regular SQL for a particular problem set, but generally it is seen as slower and more error prone, due to the (small) possibility of "stale reads" (where data that is scheduled to be updated has not yet been updated when the user reads that data).

[George]

Second sentence, did you mean SQL instead of NoSQL?

[Andrew (he/him)]

Oof, yes. It's early haha. Fixed

[Lucas Olivera]

A very clear answer, thank you very much.

[Nested Software]

This is a bit of tricky question, because the typical characteristics of NoSQL databases can be a pro or a con depending on what you want to do.

I think the single biggest idea behind NoSQL databases is that it is easier to scale them to more users (horizontal scalability). This is done by adding more servers rather than by increasing the capacity of an existing server. The downside to this is that you don't get the same guarantees with transactions that you get with (relational) SQL databases. Different users may see different versions of the same data, though usually for short periods of time - this is called "eventual consistency."

You probably don't want to use a NoSQL database to handle banking transactions. You could end up with a situation where you transfer money from one account to another, but the money appears to be both in the new account and the old one, or that it disappeared from the the old account, but isn't in the new one yet.

In really big internet applications, say social media, being able to scale is the most important thing, and having data consistency across all users isn't as valuable: Maybe I see your latest tweet, but someone else won't see it for another minute.

[Ken Bellows]

So, is it impossible, or infeasible, to implement eventual consistency with SQL databases? Is there something fundamental to how SQL DBs work that makes this difficult? If so, it seems like it would be a bummer if the problem you're solving is structurally more appropriate for SQL, but you need it to run at a very large scale and don't need the immediate consistency

[Nested Software]

There is such a thing as distributed relational databases, known as NewSQL. In fact, they seem to offer stronger guarantees than eventual consistency (in hopefully rare cases, they'll compromise on availability). For instance, Cloud Spanner, NuoDB.

[Ken Bellows]

Huh, that's super interesting! I'll have to dig deeper on that one

[Andrew (he/him)]

I'm sure @helenanders26 would have something to say about this, though.