Relational vs NoSQL databases

Which one do you prefer between Relational and NoSQL databases?

- How do you decide which one to use in your job?

- Which use cases have you identified on when using a certain kind of database?

Let us know what you think and use in your job!

Comments

[Pacharapol Withayasakpunt]

• It depends on the generosity of the hosting provider / costs.

Generous SQL (or NoSQL) hosting similar to MongoDB Atlas?

Pacharapol Withayasakpunt ・ May 29 ・ 1 min read

#database #discuss #help

• If not about money / costs, RDBMS is, in my experience, usually more performant, as well as ACID guaranteed, I think. Also, I don't really have to worry about the ORM that much. Raw SQL is pretty good enough.
• NoSQL, in my experience, is either less feature rich, or is driver / programming language dependent, or depends on the wrapper (e.g. Mongoose ODM), but it is indeed faster to write, while not necessarily harder to maintain. It is just programming language specific.
  • Also, you would probably want to avoid relationships in NoSQL, while not really have any real performance benefits in any other ways. (RDBMS can have JSON driver, with quite some performance as well; just not always easy to use.)
• Not sure if I can make up for ACIDity of the database with scheduled / frequent backup.

[mm]

You are not correct when you say “RDBMS is generally more performant“.

Nobody asked about ORM or ODM. You confused the guy. A database is not programming language specific.

“you would probably want to avoid relationships in NoSQL” there are NO relations in NoSQL.

JOIN is a feature of an SQL database which make it slow in performance. In more cases, NoSQL is more performant when you compare it to an SQL DB with JOINs. But this is very abstract. It is case specific. And we should not compare performance of these 2 since they are used in different scenarios.

Lastly, we should say that NoSQL is a collection of multiple different databases which are not SQL. It could be document-oriented like MongoDB, it could be key-value like Redis, graph DBs, etc... we should not compare what is faster, we should only compare specific cases since each of them was built for a different purpose.

[Pacharapol Withayasakpunt]

A database isn't programming-language specific, but everything else from drivers, to programming, to maintenance, are.

Otherwise, I could be wrong. I have little experience with NoSQL. NoSQL is the path less people take, and I am just advised against taking...

Also, IMO again, relationships can be anywhere, only just managed directly by the database or not.

I personally equate NoSQL to newer databases, created anew from scratch, rather than relying on SQL structure; and tried to solve problems (which can actually be unsuccessful, but marketeers won't let you know, if possible). So I do know there are multiple types. And NoSQL can also be ACID-guaranteed.

Not that the old technology, SQL, aren't getting updated. It is just not remade from scratch, that's all.

IMO, it is more of relying on cutting edge technology, or a stable technology. Again, "being made for the purpose" can fail. Only what can make sure for me are either, successful cases, or tech / liability support.

[mm]

I totally agree with the statement that SQL is older and there was no improvement for a longer time.

If we look at MongoDB, they released support for multi-document transactions in 2018. So the debate of using MongoDB vs an SQL DB specifically could be a nice topic to discuss. But still, we should focus on use cases and not performance comparison.

[Pacharapol Withayasakpunt]

MongoDB specifically, vs SQL (mentioned PostGRES) are discussed here.

PostgreSQL vs MongoDB

Ben Halpern ・ May 28 ・ 1 min read

#postgres #mongodb #healthydebate #database

Personally, I see MongoDB transactions as not yet in place, and lacking named SAVEPOINTs. And sometimes that matters a lot.

[mm]

Thanks for that. I will read it ;)

[Brandin Chiu]

How do you decide which one to use in your job?

This question is always answered by the type of data you're looking to store. In practice, we start at the end of "RDBM-first", and as the data we're storing gets flatter, the more likely we are to move closer to recommending a nosql solution.

Which use cases have you identified on when using a certain kind of database?

As mentioned above: flat, infrequently-mutated data is a perfect use case for nosql.

Why?

The main draw of nosql systems is performance. Single-row table performance of nosql systems is almost always unbeatable by nosql platforms. This is because it has stripped out most of the overhead of indexing and relation management of traditional Sql-backed systems.

This matter to us because it means we often cannot rely on the data store to help us keep our data in good shape. All of that functionality needs to be handled by our application instead. This means more code by us, but it also means that data retrieval is wicked-fast.

The flatter the data, the less each row relies on data from another, which means we don't need to care about relations. The less we need to update specific rows, the less we need to rely on our application to run prechecks to make sure we're not breaking anything or corrupting our data.

[Margo McCabe]

You may find this talk interesting - discussing different DB architectures and use cases for each of them!