我的第一个以 mongodb 作为主数据库开发的网站是 codecampo.com（2011 年），第二个是 writings.io（2013 年）。campo 在第 3 版的时候重写（2014 年）迁移到 postgresql，而 writings.io 已经关闭了，现在正在做的创业项目 selfstore.io 也是使用 postgresq
我的第一个以 mongodb 作为主数据库开发的网站是 codecampo.com（2011 年），第二个是 writings.io（2013 年）。campo 在第 3 版的时候重写（2014 年）迁移到 postgresql，而 writings.io 已经关闭了，现在正在做的创业项目 selfstore.io 也是使用 postgresql。postgresql 已经成为我的默认数据库，鉴于我曾经做过一段时间 mongodb 布道者，所以我想有必要总结一下。
我开发维护的都是流量很小的网站，所以不用期待我分享千万级数据管理的经验（我以前正式工作中倒是接触一个千万级使用 mysql 的网站，但优化工作不是我做的）。我也不会犯一些低级错误，例如项目开发到一半才困惑“mongodb 没有 join 查询怎么办？”，选型时已经知道将要面临怎样思维转换。
我不希望这篇文章被当作是“xx 已死，yy 永生”一类的噱头文章，这类文章大多带有偏见，并且对评论对象浅尝辄止。不同的工具有不同的应用场合，不能一概而论。
我从 mysql 转向 mongodb，以及从 mongodb 转向 postgresql 的最大原因都是：有趣。web 开发一个优点就是你不用限定在某个平台某类技术上，最终用户看到的都是 html 页面。
下面是一些我选择数据库的经验。
mongodb 优点无模式无模式是个双面刃。好的方面，它可以减少表的空余字段，减少拆表的必要，例如用户集合可以一条记录带有 admin: true 属性，其他不带有这个属性，而在关系数据库中这类带来大量空余字段的属性最好拆表。postgresql 打开 hstore 扩展后也可以实现这样的结构。如果觉得 admin: true 的例子太简单，可以考虑下怎么储存 gemspec 的内容并让它可索引。
无模式另一个好处是让代码逻辑管理起来更清晰，可以把属性定义和模型逻辑放在一起：
class artist include mongoid::document field :name, type: stringend
类似 datamapper 的库虽然也能实现这样的语法，但始终需要维护一个迁移脚本，需要重复自己。用 mongoid 的时候我一直觉得打开 model 文件先看到属性定义很舒服。
无模式的最大坏处就是无法真正掌握数据库中有什么内容，实际上并不是经常需要储存无模式数据，多数是模式化数据。所以即使不需要管理模式迁移，还是要管理数据迁移，每次更改属性相关逻辑时要写数据迁移脚本。这里无模式是好是坏取决于应用场景。
数据类型mongodb 支持的数据类型多于 mysql，其中最主要是 array，hash 类型。postgresql 原生或通过扩展可以支持 array 和 hash，但是配套的操作不够 mongodb 简便。
例如 mongodb 对 array 有一个 $addtoset 方法，只有数组不存在某元素时进行插入：
update( $addtoset: { upvotes_ids: 1 } )
而 postgresql 要进行同样操作需要组合一些语句：
set upvotes_ids = array_append(upvotes_ids ,1) where not (upvotes_ids @>array[1])
mongodb 的语句更简洁，也不排除 postgresql 以后也会添加同样的方法。
mongodb 缺点不支持事务也许需不需要数据库事务成了是否选择 mongodb 的决定性因素，mongodb 不支持数据库事务。
有很多应用对数据一致性其实要求不高，例如很多社交应用，大多数应用逻辑只是简单存取（发一段文字，上传一张照片），极少的不一致是不影响应用的。而一些严肃应用，例如交易系统，就很需要数据库事务的支持了，否则就需要在应用层自己实现一个粗糙的、充满 bug 的事务支持。如果有兴趣自己实现事务操作，可以看 mongodb 的文章 perform two phase commits。
如果有跨系统的事务操作，就不能完全依赖数据库事务，还要有应用层的重试或回滚操作（例如远程调用支付接口）。数据库层面支持事务的话，起码让维护系统内部数据一致性更轻松。
查询语法mongodb 的原生查询语法是 javascript，javascript 程序员可能对此欣喜若狂。我最初感觉也是很新鲜，但久了就觉得很烦躁。javascript 太多的括号和花括号，在组合多个查询条件的时候作括号匹配很费神。sql 是一个查询 dsl，虽然看起来有点古老，但是在查询这个特定领域上做得很好。
如果应用使用 orm，可能很多时候不需要写原生查询语句。除了 php 社区外，其他社区也不推荐写原生查询。不过少数情况下，复杂查询还是原生语句更高效，而且数据库终端也是调试查询错误的最终手段，所以查询语法至少不能让人难受。
默认不安全mongodb 的开发者假设你是一个资深系统管理员，并且把 mongodb 部署在安全的内部网络当中，所以他们官方安装包内含的配置没有设置任何安全验证，接收任何来源的访问，结果就是一些初级系统管理员（例如我）把 mongodb 直接暴露到了公网，造成数据泄漏。
这不仅是 mongodb 的问题，redis、elasticsearch 也是这样，姑且把这认为是一种设计“哲学”。ubuntu 的软件源管理者不认同这个“哲学”，从软件源安装的 mongodb 的默认只接受本地连接，这保护了一些初级系统管理员，但如果追新使用数据库开发方的安装包就会中招。顺便一提，postgresql 默认配置只接受本地连接。
无论用什么数据库都好，使用前一定要完整读一遍文档，特别是设置和安全相关的章节，同时设置系统防火墙。
库mongodb 的官方驱动更新没有问题，不过一般不会直接使用驱动写程序（写过，很繁琐），而是使用 odm（对象-文档映射）工具，在 ruby 中就是 mongoid。
mongoid 已经做得很好，提供了类似 activerecord 的 api，并且很好的利用了 mongodb 的特性，但在关注度和社区规模上还不及 activerecord。activerecord 作为 rails 的默认组件，每次都是跟随 rails 的更新同时更新的，mongoid 则要滞后一段时间。所以如果你希望紧跟 rails 的更新，那么最好使用 activerecord 和关系数据库。
为什么是 postgresql 而不是 mysql/mariadb今年开始，我的精力投入到一个交易网站的开发，所以一开始就打算迁移到关系数据库。至于为什么用 postgresql 而不是 mysql/mariadb，有几个理由：
有趣，我还没用过 postgresql。postgresql 的数据类型更多，我主要需要 array 和 hstore。这些数据类型可以减少开发量，在 mysql 实现 tag 属性需要多两张表。过去的工作中让我接触到 mysql 不好的一面，例如因为 join 性能不好（我没验证过），不允许用 includes 方法，基本上只做主键查询，所以我之前那么容易接受 mongodb。mysql 被 oracle 收购后社区出现分裂（mariadb），我对 oracle 印象也不好，前公司旗下一个网站因为域名带有 java 而收到律师函，所以我尽可能避开 oracle 的产品。postgresql 的社区热度在增加，activerecord 对其特性的支持也在完善。基于以上理由，我选择了 postgresql，目前为止工作得很好。
总结这几年间我接触了 3 个数据库（不包括 redis 的话），sql-nosql-sql 的切换让我对数据库有了更深刻的理解，也认识到还有很多类型数据库我没试过，关系数据库不是唯一选择。我的几个项目都是只是玩具规模，没什么说服力，但以免被误解，还是提几条建议：
如果当前数据库用得很好，就没必要更换。如果没有明确的数据库需求，那么用关系数据库。如果要开发新的项目，推荐 postgresql。最终，选择要取决于你的应用场景。
原文地址：为什么我从 mongodb 迁移到 postgresql, 感谢原作者分享。