PostgreSQL 的 MVCC 很糟，其他数据库也一样
PostgreSQL's MVCC is bad. So is everyone else's
很多人批评 PostgreSQL 的 MVCC 设计是 40 年前的错误，导致表膨胀、写放大和 VACUUM 噩梦，甚至 Uber 因此迁移到 MySQL。但文章指出，这些并非缺陷而是设计选择。任何支持读写不阻塞的数据库都必须实现 MVCC，只是不同引擎在旧版本存储位置、索引指向和清理机制上做出了不同取舍。PostgreSQL 将成本转嫁给运维，而其他方案则将负担推给写入者或缓存。没有完美的方案，只有不同的代价。
任何想要读者不阻塞写入者的数据库，都必须在某处保留多行版本，而每个这样做的引擎都必须回答同样的四个问题。
HN 评论区
22- gtowey
我对这篇文章心情复杂。它确实包含了很多有价值的信息，也很有用，对比了 PostgreSQL 和 MySQL 的核心差异。但它仍然充斥着大量 LLM 式的陈词滥调，让人看了很不舒服，一看到这些我就想关掉页面不读了。
- shayonj
> Nothing was solved. The four questions got new answers, and the costs moved into the compactor.
我一直想写点关于这个话题以及 LSM 的内容。所以我很欣赏文中关于 LSM 的那段注记。这世上没有免费的~午餐~，也没有免费的读或写操作。
- jhgb
我很惊讶，尽管 Interbase/Firebird 是 MVCC 方法的先驱，这篇文章似乎却完全忽略了它们。