When you have a very large number of child records associated to the same account in Salesforce, we call that “data skew”. It can seem like the obviously right thing to do – for example, when you have a whole bunch of unassigned contacts and need some place to “park” them, it’s tempting to put them all under one account name ‘Unassigned’. Unfortunately this can cause issues with record locking and sharing performance. Let’s say you are updating a large number of contacts under the same account in multiple threads. For each update the system locks both the contact being changed and its parent account, to maintain integrity in the database. Even though each lock is held for a very short time, because all the updates are trying to lock the same account, there is a high risk that an update will fail because a previous one is still holding the lock on the account. There’s a similar dynamic in sharing. Depending on how you have sharing configured, when you do something that seems simple like changing the owner of that account, we may need to examine every one of those child records and adjust their sharing as well. That may include recalculating the role hierarchy and sharing rules. This can take a while if we are talking about hundreds of thousands of child records.

So how do you keep a lid on data skew to avoid these issues? To start, we recommend that you avoid associating more than about 10k child records to a single parent record. If you need to do something like the “parking lot” example above, you can create a larger number of accounts and modify your integration code or use a trigger on the child object to distribute the child records across this collection of “parking” accounts. This will help to avoid the locking and performance issues you might experience with a highly skewed account.