DEV Community

Domenico Solazzo
Domenico Solazzo

Posted on

Relational vs NoSQL databases

Which one do you prefer between Relational and NoSQL databases?

Alt Text

- 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!

Top comments (8)

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited
  • It depends on the generosity of the hosting provider / costs.
  • 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.
Collapse
 
michalmoravik profile image
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.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited

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.

Thread Thread
 
michalmoravik profile image
mm • Edited

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.

Thread Thread
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited

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

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

Thread Thread
 
michalmoravik profile image
mm

Thanks for that. I will read it ;)

Collapse
 
brandinchiu profile image
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.

Collapse
 
margo_hdb profile image
Margo McCabe

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