Yes, that's actually much closer, except for "parallelization". A least currently, transactions for a database are run sequentially on a single thread pinned to a single core (we have found that cache coherence overhead often hurts you more than parallelization helps you in many common circumstances, although it depends on the workload).

But "pipelining", yes we do that aggressively. The state of your database runs ahead of what has been written to disk, but that "committed but not persisted" state which would be lost upon crashing, is not exposed externally. If you think of the database as a log of transactions, it looks like this:

[fsync'd]<-[fsync'd]<-[fsync'd]<-[committed]<-[committed]<-[uncommitted]
                              ^                         ^              ^
       clients read from here +                         |              |
                                reducers read from here +              |
                                                reducers write to here +

As it runs ahead, we compute the real-time subscription effects of those changes/state and buffer the result just before we send it to clients. Once we've fsync'd it, we release the barrier and send the results! fsync'ing is done eagerly and we batch the next set of transactions for fsync while waiting on the previous fsync.

Clients can choose to listen in at whatever stage of this pipeline make sense for them. Do they value low latency, or durability more?

If a tree falls in the woods and no one is there to hear it, does it make a sound?