A modern database deals with multiple long lived independent transactions that can independently be committed or rolled back, involve independent, isolated views of what the contents of the database look like that evolve as each transaction progresses, row level locking so that no more than one uncommitted version of a row exists at any given time, and multiple version concurrency control so that all other readers only see the previously committed versions of rows.
POSIX filesystem semantics don't have anything like it - in fact they actually forbid it. There is only one view of the filesystem to all user processes, and everything that happens takes effect instantaneously. No isolation, no process specific view of the contents of files or directories, no (user visible) transaction commit or rollback.
Everything a strict POSIX filesystem does with transactions is for recovery purposes, in an attempt to recreate something resembling a consistent snapshot of the system at the time it failed, or at least a working inconsistent one. And certainly one would want to pipeline the assembly and retiring of those transactions, so that the next one can be constructed while previous ones are being retired. I am glad to hear that Tux3 does just that.