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.
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.
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.
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.
Generous SQL (or NoSQL) hosting similar to MongoDB Atlas?
Pacharapol Withayasakpunt ・ May 29 ・ 1 min read
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.
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.
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.
MongoDB specifically, vs SQL (mentioned PostGRES) are discussed here.
PostgreSQL vs MongoDB
Ben Halpern ・ May 28 ・ 1 min read
Personally, I see MongoDB transactions as not yet in place, and lacking named SAVEPOINTs. And sometimes that matters a lot.
Thanks for that. I will read it ;)