Deferred tables are there to eliminate contention. When you have processes like MRP with multiple threads (processors/schedulers) and what happens if two of those both need to change the PartQty? Locking/blocking/deadlocks ← fun fact: deadlocks are almost 100% software issues assuming of course that there aren’t any external processes in play. So, what we did instead is for processes that have current threads trying to update the same records (MRP, Posting) we created these deferred tables to insert a new record into the deferred table instead of updating the actual record directly to avoid the contention. After the transaction is complete, the actual record is updated - so in practice, it isn’t slower. There is some additional logic that says that after a period of time if that record is in the deferred table too long (~15 minutes I believe) it will process it immediately like if the appserver went down in the middle of processing - this is triggered from the taskagent.