MVCC doesn't have to work the way Postgres does it. In some other databases a write like a DELETE or UPDTE directly overwrites disk blocks in place. There are no row copies or vacuums. To provide MVCC the database generates "undo logs" which are what they sound like - if you need to read the database at an earlier snapshot it reads the data off disk then use the undo data to revert the writes that happened after your MVCC snapshot. Undo data is periodically dropped when no live transaction needs it anymore.

There are patches to change Postgres to this kind of model, as it has many advantages - all the outages and problems caused by autovacuuming falling behind go away - but the patches were never merged.

Oracle has a couple of related features:

- undo data can be retained and used for time travel queries (SELECT .. AS OF).

- DML can be parallelized and write masters scale horizontally, so a large DELETE can run on multiple machines simultaneously. You do need to opt in manually though:

    ALTER SESSION ENABLE PARALLEL DML;

    DELETE /*+ PARALLEL(t, 8) */
    FROM   t
    WHERE  created_at < :cutoff;

    COMMIT;

That said the issues discussed in the blog post aren't directly to do with how fast the DELETE itself is processed but what it does to the database's performance afterwards.

Disclosure: I have a part time role in the Oracle DB group.