Right now all write transactions are done synchronously, which is obviously not optimal as they end up blocking other events from taking place while the transaction is in progress (which involves IO).

The reason that transactions can not just be done asynchronously on background threads is that they involve javascript code (the actual code changing the data), so that code has to run on the main javascript thread. But doing a transaction is actually composed of multiple steps, some of which could done asynchronously:

1. Advance to latest version (can be done async)
2. Do changes (has to be done in javascript on the main thread)
3. Commit to disk (can be done async)

Advance to latest version
Before starting a transaction you always have to update the state of the entire realm to the latest version. If you did not do this, the actual code being done in the transaction would risk working on stale data.

This is a potentially blocking operation, as another transaction may be in progress, so you have to wait for that to complete before you can advance to the latest version. But this waiting can be done asynchronously on a background thread, so that the javascript event loop can continue doing other work while waiting for the for the advance to complete.

Do changes
This is javascript code, so it has to run on the main javascript thread.

Commit to disk
This can again be done on a background thread so that the event loop can progress doing other stuff while it completes.

Moving these parts of the transaction process to background threads would not affect the throughput if the main constraint is transactions on the same realm (since the transactions would still have to wait for each other to complete), but it would free up the event loop to do other work while the transactions are in process, and if you are working with multiple realms they could also do transactions in parallel.