The terms async and parallel are often interchanged, though async means that something out of band happens relative to the main flow of execution (thus interrupting the main flow of execution), often this interruption can be in service of an I/O completion routine. Thus, async implies (potentially arbitrarily timed) interruption of the main thread, and not necessarily with a full blown second thread. On some systems (but not JavaScript), the main thread is temporarily suspended and then high-jacked to service the I/O completion routine (then the suspended work is resumed).
Whereas parallel means two or more things (threads) happen simultaneously. On a uniprocessor there is no true parallel execution; however, it is simulated by interrupting whatever thread is currently running (and often at an arbitrary point) in order to give some CPU time to another thread. On a multiprocessor systems, there will be both simultaneous execution by different CPUs, as well as interruption for the purposes of interleaving thread execution to run more threads than the CPU has.
(If you will, async is a lightweight form of (pseudo) parallelism, where the one thing is the main thread, and the other thing isn't necessarily a true full blown thread, but rather an I/O completion routine.)
Let's also note that JavaScript is inherently single threaded. That is to say, there is no true parallel execution even on a multiprocessor chip, whereas in C, C++, Java or C#, you can have truely simultaneously executing threads on a multiprocessor chip. JavaScript has no notion of threads, but it does have callbacks.
Callbacks (function references) that you provide to some other routine may be synchronously executed or they may be asynchronously executed. It really depends on how those callbacks are used: you actually cannot tell from the code that passes the callback (without knowing the library routine to whom the callback is supplied). So callbacks don't immediately imply asynchronous execution.
(Callbacks are further complicated in that the function reference may actually be used zero or more times; there is basically no inherent guarantee from the semantics of the language as to when or how many times a callback is used.)
In your example, it would appear that the callback(s) are executed synchronously with respect to -- and under direct control of -- the main thread.
Asynchronous execution happens in JavaScript as a result of I/O (or timeout) completion routines. Since JavaScript is inherently single threaded, the way this works is that the (one) main thread is allowed to run to 100% completion -- to return to its caller (which is the JavaScript scheduler). At this point, there is no main thread running anymore, and, the JavaScript scheduler can invoke completion routines using that main thread. If multiple I/O requests trigger multiple completion routines, they are each run 100% to completion, one after another, in the order they are scheduled (which is the order of the I/O completion) without any interleaving.
(Of course, the I/O completion routine may itself make additional I/O calls, passing subsequent I/O completion callbacks; the overall execution of that set of completion routines would be interleaved with other such I/O completion callbacks as described above.)
In your case, the callbacks are executed by function reference invocation, which makes them run under regular control of the main thread. The mechanism is indirect function call, so your callbacks are invoked using the standard function invocation mechanism. The main thread does not run to completion; the callbacks are not scheduled to run but are rather directly invoked. To see the difference, you might substitute:
callback(null, result);
with
setTimeout(callback,100,null,result);
This would also invoke the callback, but it would wait until some time after the currently executing routine (and the whole thread, in fact) has returned to its caller.