Oracle, with its undo log and some clever in-place tuple modification and space reclamation, seems to have sidestepped the issue to a much greater degree than P

Oracle, with its undo log and some clever in-place tuple modification and space reclamation, seems to have sidestepped the issue to a much greater degree than Postgres. Oracle is MVCC-like, but sacrifices technical elegance for performance. For example, as I recall, Oracle actually writes new row data to the page the row lives in, overwriting the old data in place on commit. It also writes the modifying transaction ID to the row header. If a different transaction finds the row, it will see that the transaction ID doesn't match (it's newer than itself), which forces the database to go to the undo log to look for the older data. I'm not privy to the technical details of how the undo log is implemented or how it avoids the vacuum problem. I suspect it's related to the fact that the undo log is separate from the tuple data, so undo bloat doesn't affect table performance to the same extent as with Postgres.