编程与软件工程developer.olery.com
再见 MongoDB，你好 PostgreSQL
Goodbye MongoDB, Hello PostgreSQL
2015 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Olery 团队回顾他们从 MongoDB 迁移到 PostgreSQL 的经历：随着业务增长，MongoDB 的无模式设计、一致性与可靠性问题逐渐成为负担，而 PostgreSQL 在数据完整性、查询能力和运维稳定性上表现更好。文章详细对比了两者在 schema、事务、聚合查询等方面的差异。
为什么经久不衰：它是 NoSQL 热潮退潮期的代表性复盘：许多团队都会经历从 MongoDB 起步、随规模增长转向关系型数据库的过程，这篇迁移实录至今仍有参考价值。
HN 评论精选
老牌 SQL 数据库一直很好用，年轻人应警惕盲目追逐新技术，并直接学 SQL 而非依赖 ORM。
作为一个头发花白的老开发者，看到人们发现 SQL 数据库这类'老'技术其实非常好用，我觉得很有趣。我能给年轻开发者的唯一有用建议是……喝新技术的迷魂汤时要小心。另外，那段用 ORM 包装 SQL 的代码让我想哭——去学 SQL 本身，而不是包装它。
jgrahamc查看英文原文
As a greying developer I am most amused by people discovering that 'old' technologies like SQL databases work really well. The only useful piece of advice I can give a younger developer is... be careful when drinking the newtech koolaid. And one more thing: star = Sequel.lit('*') User.select(:locale) .select_append { count(star).as(:amount) } .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percentage) } .group(:locale) .order(Sequel.desc(:percentage)) just makes me want to cry. Learn SQL rather than wrapping it.
MongoDB 适合早期快速迭代，规模化后缺点显现，迁往 Postgres 是自然演进而非对 Mongo 的否定。
这篇文章反映了公司成长后从 MongoDB 迁回传统关系型数据库的有趣技术叙事。但我认为这不是对 MongoDB 的否定，而是凸显了 NoSQL 的核心优势：易用和快速迭代。项目初期 MongoDB 非常容易上手，不用建表、不用随产品方向调整而频繁改 schema，因此非常适合早期创业公司。但当公司规模化后，无模式存储等早期优势就变成了缺点，可靠性变得更重要，于是人们自然转向更传统的数据库。
morgante查看英文原文
This post reflects an interesting technical narrative of companies switching off MongoDB to more traditional relational databases as they grow. Importantly, I don't think that's an indictment of MongoDB. Instead, it highlights the key advantages of NoSQL: ease of use and rapid iteration. When you're first working on a project, MongoDB is very easy to slap in. You don't even have to create tables/collections. As you iterate, you don't have to constantly be updating schemas as your product direction shifts. Thus, MongoDB is perfect for early startups. As a company scales, of course it's warts start to show. The very attributes (like schemaless storage) which were an asset when just a few developers were hacking on the project become a drawback as the company grows in size. Reliability becomes more of a concern. Naturally, people shift to a more traditional database. Personally, I'm almost ready to switch some of our core functionality from MongoDB to Postgres. This isn't an indictment of Mongo though.
无模式是 MongoDB 的设计取舍而非缺陷，但它在一致性和内存成本上确实不适合做主数据存储。
无模式存储的意思就是'没有 schema，不同对象可以有不同字段'，这正是 MongoDB 的核心：你把管理 schema 的责任揽到自己身上，以此换取灵活性。文章第二个理由更站得住脚：MongoDB 不够一致和持久，适合做缓存而非长期数据存储。第三个反对理由是成本：你必须把整个数据集放在内存里，比如 Foursquare 曾把所有历史签到都放在内存里，这完全没必要，为此付出了高昂代价。
IgorPartola查看英文原文
> Another way of handling this is defining a schema in your models. For example, Mongoid, a popular MongoDB ODM for Ruby, lets you do just that. However, when defining a schema using such tools one should wonder why they aren’t defining the schema in the database itself. Bah. It's like they didn't know that schema-free data stores mean "there is no schema; different objects may have different fields". This is the whole point of MongoDB: you assume the responsibility of managing the schema. That's a "feature": you get greater flexibility by assuming more responsibility. Whether it's a useful feature, I won't say. Their second reason is much more valid: MongoDB is not consistent/durable, all that. It's good for a cache, but not for long term data. Here's a third reason I'd give against it as your primary data store: it's expensive. You have to keep your entire dataset in RAM, but that's not always necessary. My favorite example is from Foursquare. They had every single check-in ever in MongoDB in RAM. That's absolutely unnecessary, and quite silly to do so. Old check-ins are archived data. You don't need them. No user ever wants to know when/where they checked in three years ago. This is why at the time they were paying for 68 GB RAM Amazon boxes instead of 4-8 GB boxes. (I have no idea what they do now. I remember chatting with them on HN after a catastrophic out of memory failure when they filled up the entire 68 GB's).
换数据库不能替代对数据库原理的理解，不搞清楚问题根源就盲目迁移，在新工具上还会重蹈覆辙。
这类'我不知道哪里出了问题'的文章在 Mongo 身上很常见。我的团队管理着数千个 Mongo 节点，有问题但很少是 Mongo 本身导致的。你必须真正理解数据库，'迁移到 Postgres'并不能替代对数据库内部机制的理解和排查坏访问模式的能力。盲目迁移数据是最糟糕的事情之一——问题没解决，换新工具后还会再咬你一口。
jb3689查看英文原文
"I don't know what was wrong" articles like this come up really often with Mongo. My team manages thousands of Mongo nodes and we have issues, but few are directly due to Mongo. Mongo's documentation could be friendlier to the operator/maintainer, however the tools for debugging Mongo tend to be sufficient (metric counters, various status/state dumps, general Linux tooling). You need to understand databases folks. There is no way around it. "Porting to Postgres" does not replace understanding of database internals and figuring out how to debug bad access patterns and explain why they are bad. Blindly migrating data seems like one of the worst things you could ever do - you're not fixing the problem that you don't understand how databases work. I get it - ain't nobody got time for that - but it will come back and bite you with your new shiny fancy tool too if you aren't careful Anyone who brings up something like master-master hopefully realizes they are talking about a completely different problem now with completely different constraints. Expecting the same access pattern will perform just as well in master-master is wishful thinking - it requires careful design to avoid coordination problems. The meat of the story with databases is: coordination is expensive, distributed coordination is even more expensive
SQL 数据库吸收了 NoSQL 的优点（JSON 列、多主复制），如今新项目已没有理由选 NoSQL。
我用过 NoSQL 和 SQL 数据库。完善的复制拓扑（如多主配置）和 JSON 列杀死了 NoSQL 运动。我很高兴 NoSQL 运动存在过，它迫使 SQL 阵营跳出固有思维，但今天在全新项目上我不会再选任何 NoSQL 方案。
anticristi查看英文原文
I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选