Both @fibric and @sandeep have explained it much better than I could, but one thing worth pointing out, is that this statement isn't correct in the first place > "requests having some sort of blocking task like DB access or some sort of File System access that needs a separate thread from node's single thread of execution."
These operations don't really "go to a thread" that waits for them. From the libuv docs ( http://docs.libuv.org/en/v1.x/design.html ):
The event loop follows the rather usual single threaded asynchronous I/O approach: all (network) I/O is performed on non-blocking sockets which are polled using the best mechanism available on the given platform
All I/O is handled through signal handling mechanics that don't require an active thread.
If you read that doc, you'll see some temporary blocking is involved for signal handling, meaning blocking happens for only a small fraction of the complete wait time[*].
So yes, libuv (and by consequence node.js) is as non-blocking as it gets.
[*] at the File System level, this depends heavily on the platform and the Filesystem in use, but libuv will ALWAYS try to use the best mechanism possible.