What makes Node unique in terms of platform features is that it is designed to be functional and non-blocking from the ground up. Each library is already set up to use some kind of callback pattern, and the platform architecture forces the developer to adhere. There are benefits to this paradigm, but they don't really matter.
Yes, Node's nonblocking IO and other features are great terms of scalability and performance, but these benefits don't really explain the uptake of Node as a first-implementation language. I would bet that 90% of the applications written in Node never get to a volume where the performance considerations matter. And those that do still end up needing custom performance features written in a compiled language.
But I hear the word "just" a lot, implying simplicity -- "just build it in Node". So what's going on?
Node is not only the same language as the front-end, but also the same programming concepts: event-based, callbacks, etc. This avoids shifting into the paradigm of imperative style, with blocking multithreading, big classes, etc. This, coupled with avoiding the specialized knowledge of build cycles and compilation and artifact deployment, makes it feel "just easier". And it is.
What about no-sql? Everything I said about Node is probably true for Mongo.
Writing to no-sql databases really looks very similar to the list/hash data structures that appear on the front end. It avoids the specialized knowledge of DDL. Data migration is done in functional/reactive programming.
That's what makes the node/nosql stack so compelling -- it's all the same paradigm, and it matches the browser-side paradigm, which is the one you can't change. This isn't bad, necessarily. In fact, it may be the kind of thinking that unlocks Node for a lot of teams.