Postgres made the foundational design decision that every update is an insert leaving behind a stale row that'll get cleaned up eventually with its MVCC model. It's great for non-blocking read-heavy workflows (presumably the most common), but it suffers for the inverse.

For example, I wrote a simple job queue in Postgres, which had a lot of contention over the oldest rows non-terminal rows. It had many runners trying to either mark a row as completed or claim a row by atomically marking it as started and returning the row's contents (using the "skip locked" functionality). This ran much faster using similar semantics on MS SQL Server or MySQL because they have in-place updates, not an append-only tuple log.