PostgreSQL reconsiders its process-based model

https://en.m.wikipedia.org/wiki/Redo_log

In case anyone else was briefly confused, MariaDB has both undo and redo logs. Redo logs are for error recovery, undo logs are for handling rollbacks. PostgreSQL has redo logs (aka Write Ahead Logs aka WAL), but no undo logs. It handles rollbacks via MVCC.

Advantages of undo logs are that outdated data take no space in data files, but accessing outdated data requires special actions and can be a bottleneck for concurrency. MVCC means outdated data stays in place, so no limits on transaction size. But you need something like VACUUM to maintain performance over time.

Actually, one of the most useful features I find with PostgreSQL is that schema changes are transactional. That makes migrations so much easier to manage since you don't have to worry about partial failure. You can run entire scripts changing tables, migrating data, altering foreign keys and if halfway something goes wrong, rollback and you're back in business. Talking to colleagues using MariaDB, schema changes always seem to be extremely painful. (Oracle doesn't support DDL in transactions either, helpfully autocommitting the transaction you were in.)

A PostgreSQL parser on a MariaDB database feels like some kind of frankenmonster I wouldn't touch with a very long barge-pole.