68

Recently I've been playing around with Node.js a little bit. In my particular case I wound up using MongoDB, partly because it made sense for that project because it was very simple, and partly because Mongoose seemed to be an extremely simple way to get started with it.

I've noticed that there seems to be a degree of antipathy towards relational databases when using Node.js. They seem to be poorly supported compared to non-relational databases within the Node.js ecosystem, but I can't seem to find a concise reason for this.

So, my question is, is there a solid technical reason why relational databases are a poorer fit for working with Node.js than alternatives such as MongoDB?

EDIT: Just want to clarify a few things:

  • I'm specifically not looking for details relating to a specific application I'm building
  • Nor am I looking for non-technical reasons (for example, I'm not after answers like "Node and MongoDB are both new so developers use them together")

What I am looking for is entirely technical reasons, ONLY. For instance, if there were a technical reason why relational databases performed unusually poorly when used with Node.js, then that would be the kind of thing I'm looking for (note that from the answers so far it doesn't appear that is the case)

Matthew Daly
  • 9,212
  • 2
  • 42
  • 83
  • 1
    This was closed elsewhere: http://programmers.stackexchange.com/questions/198224/why-is-mongodb-popular-with-node-js – WiredPrairie Aug 22 '13 at 11:13

5 Answers5

40

No, there isn't a technical reason. It's mostly just opinion and using NoSQL with Node.js is currently a popular choice.

Granted, Node's ecosystem is largely community-driven. Everything beyond Node's core API requires community involvement. And, certainly, people will be more likely to support what aligns with their personal preferences.

But, many still use and support relational databases with Node.js. Some notable projects include:

Jonathan Lonowski
  • 121,453
  • 34
  • 200
  • 199
30

I love Node.js, but with Node it actually makes more sense to use a RDBMs, as opposed to a non-relational DB. With a noSQL/non-relational solution you often need to do manual joins in your Node.js code and sometimes work with a lack of transactions, a technical feature of RDBMs that have commit/rollback features. Here are some potential problems with using Non-Relational DBs + Node.js servers:

(a) the joins are slower and responses are slower, because Node is not C/C++

(b) the expensive joins block your event loop, because the join is happening in your Node.js code not on some database server

(c) manually writing joins is often difficult and error-prone; your noSQL queries could easily be incorrect or your join code might be incorrect or suboptimal; optimized joins have been done before by the masters of RDBMs, and joins in RDBMs are proven to be correct, mathematically in most cases.

(d) Some non-relational databases, like MongoDB, do not support transactions - in my team's case, that means we have to use an external distributed lock so that multiple queries can be grouped together into an atomic transaction. It would be somewhat easier if we could just use transactions and avoid application level locks.

with a more powerful relational database system that can do optimized joins in C/C++ on the database server rather than in your Node.js code, you let your Node.js server do what it's best at.

With that being said, I think it's pretty f*ing stupid that many major noSQL vendors don't support joins (?) Complete de-normalization is only a dream as far as I can see it. And the lack of transactions can be a bit weird. Without transactions, only one query is atomic, you cannot make multiple queries atomic without an application level locking mechanism :/

Take-aways:

If you want non-relational persistence - why not simply de-normalize a relational database? There is nobody forcing you to use a traditional database in a relational manner.

If you use a relational DB with Node.js I recommend this ORM: https://github.com/typeorm/typeorm

As an aside, I prefer the term "non-relational" as opposed to "noSQL".

Alexander Mills
  • 90,741
  • 139
  • 482
  • 817
  • Node utilizes Chrome V8, which is open-source Chromium C++ (array functions are blazingly fast), and headless Chrome is better than PhantomJS nowadays, which is pretty much deprecated – neaumusic Jun 07 '18 at 01:32
  • (a) says joins are slower because Node.js isn’t C++, but it actually should be, because of Chrome V8, which transpiles and optimizes array functions using C++ native counterpart – neaumusic Jun 07 '18 at 09:54
  • I see what you're saying. I think that's just a problem with external data, not that Node.js is managing or interfacing with the DB. Usually, JS <--> native code works via eventing, so each env / thread / process can do other things while waiting for a potential response, but I think you're right it would involve an iteration of deep copy / stringify so that Node.js data can be ingested in performant service – neaumusic Jun 07 '18 at 22:12
  • The question is about using relational vs non-relational database with Node.js. To me, relational vs non-relational is choice about using baked in, performant optimizations for relational querying and data integrity / updating. Node.js is just a non-blocking way to utilize system-level drivers with JavaScript syntax. If the code is executing in V8 or Node.js, it already has a C++ counterpart to the JS representation! – neaumusic Jun 07 '18 at 22:25
  • All I am saying, is if you write code in C++ and write code in JS, the equivalent C++ code will generally run at least 10x faster, that is simply the result of compiled code. So if you are paying for hardware to run your code on, you'd generally want your code running in C++. With databases, the C++ has already been written to a certain extent, so might as well use it. That being said, there surely are some use cases, where application code could do some work and take a load off the database server(s). – Alexander Mills Jun 07 '18 at 23:17
  • 1
    *The reason why people use JS instead of C++ is because C++ requires more work, but with databases, the C++ has already been written to a certain extent, so might as well use it. – Alexander Mills Jun 07 '18 at 23:24
  • 1
    Amendment to what i said above: looks like JS code is compiled once, and then basically everything is executed in V8 (C++ land), so data does *not* cross the JS to C++ boundary for every I/O call, as far as I currently know. – Alexander Mills Sep 25 '18 at 21:50
  • NoSql schema design is hard. If done correctly by understading query patterns, one can ensure one never needs transactions or joins. – Apurva Singh Nov 21 '20 at 21:52
17

In my experience node tends to be popular with databases that have a stateless API, this fits very nicely into nodes async nature. Most relational databases utilize stateful connections for transactions, this minimizes the primary advantages of async non-block i/o.

Alex Savenok
  • 187
  • 1
  • 3
  • makes most sense. Two top answers are misleading and those folks don't understand NoSql schema design. They are designing like rel dbs, normalizing and stuff, and then complaining that they want transactions. – Apurva Singh Nov 25 '20 at 20:31
  • Aren't databases stateful by nature? Why is the NoSQL stateless? – Ngọc Nguyễn Nov 21 '22 at 02:55
12

Can you explain exactly what specific problems you are facing with your chosen database and node.js?

A few reasons why MongoDB could be more popular than relational databases:

  • MongoDB is essentially a JSON object store, so it translates very well for a javascript application. MongoDB functions are javascript functions.

  • I am just guessing here, but since NoSQL databases are newer and have more enthusiastic programmers experimenting with it, you probably have more involvement in those NPM modules.

Apart from this, Node.js technically is a perfect choice for any sort of database application. I have personally worked on a small Node.js/MySQL application and I didn't face any hurdles.

But back to my main point, we could talk about this all day, and that is not what this forum is for. If you have any specific issues in any code with Node.js and your database of choice, please ask those questions instead.

Edit: Strictly technical reasons, apart from the JSON compatibility on both sides: There are none.

Munim
  • 6,310
  • 2
  • 35
  • 44
  • I've clarified my question a little to exclude non-technical answers. I'm looking only for entirely technical reasons (if any) why a developer should not use a relational database with Node.js. – Matthew Daly Aug 22 '13 at 12:29
  • 2
    @MatthewDaly Strictly technical reasons, apart from the JSON compatibility on both sides: There are none. Feel free to use your Node.js with your relational data store. As long as it is a popular one like MySQL or PostgreSQL, you shouldn't run into any issues. – Munim Aug 22 '13 at 13:05
3

Anyone wondering about the same question in 2021-

  1. Node has nothing to do with type of databse you choose.

  2. You can choose database of your choice as per your requirement. If you need to maintain strict data structure then choose relational db, else you can go for NO-SQL.

  3. There are NPM packages for PostgreSQL, MySql and other db which are non-blocking. These db clients will not block the Node process while performing queries.

Kapil Sharma
  • 169
  • 6