When Node.js is described as "non-blocking", that specifically means that its IO is non-blocking. Node uses libuv to handle its IO in a platform-agnostic way. On Windows, it uses IO completion ports, on Unix, it uses epoll/kqueue/select/etc. So, it makes a non-blocking IO request (which may have a background thread monitoring, but this is never exposed to JavaScript) and upon a result, it queues it within the event loop which calls the JavaScript callback on the main (read: only) JavaScript thread.
For databases, it depends on how the library is written. If it uses HTTP to communicate (as some NoSQL databases do), then it could be easily written in pure JavaScript using the standard node http library. If it does it another way, well, that's up to the library. It could be written in C/C++ and use background threads as long as that abstraction is never exposed to the JavaScript.
As for your question of what is "processing" the database request, ideally all that should be done is sending a simple message to a library (e.g. a SQL statement or some other query or a request to connect), and at that point your JavaScript keeps on chugging. When the library is ready to send a message back, it sends a message back to node's event queue which runs the callback, allowing that snippet of code to run.