The answer for this, as mostly in UX, it depends on the context.
A Common Use Case
This is a very common use case - the user performs an action and it takes time to "complete the transaction" (ie, changes to be flushed to the database).
You should also consider off-line mode, where devices are offline, so changes a stored locally, but only flush to the online database when the device connects to the internet. For example, if I'm offline and delete an email on my iPhone - it will be removed from the UI, although it wasn't remove from anywhere else (there is a queue and some indication that the mail application is attempting some tasks, but it is not exactly prioritise in terms of UI).
Does It Matter for The User?
If the user have span a virtual machine instance on Google Cloud, and gets billed by the hour, and requests to terminate the instance, it is important for the user to know that termination is in progress, and when it was completed. The user payment will continue if case the termination failed.
Similarly, it is important that an item I requested to remove from my shopping basket has been removed.
However, when the result of failure is not as consequential, and is a simple case of "this is going to take a bit of time", a strategy called optimistic update is taken - the UI behaves as if the record was removed, while the actual removal is pending in the background (or in some cases queue locally until connection is restored).
Optimistic Update Handling
Like the mail app mentioned above, sometimes it pays to expose the pending status to the user.
The main concern is usually - what happens in a case of failure? There are various strategies for this, and one should consider a case where the user has already navigated away from the screen where the record was shown.
A notification is one way dealing with this.
Other considirations
Should we keep the row with its content visible while deletion is in progress or remove it?
If the row is visible, it should be disabled to prevent the user from interaction with it (otherwise the user may perform an "inconsistent" action, like trying to edit a record after requesting to delete it).
A possible idea is to grey-out rows during deletion and then remove them (if deletion was successful) or return to a normal state (if deletion failed).
There is an assumption here that the user will still be on the same page when this happens, which is not always the case (unless you block the UI while the transaction is pending, which is not great UX in most cases).
Further, there is a question of "will the use notice this?" and what are the consequences if not.
So it really boils done to the specifics of the system in question here. I don't think sufficient information has been provided to give an informed best practices. What is the nature of the records? What are the consequences if the user misses a failure?
