PostgreSQL JSONB与MongoDB对比：社交媒体用户内容存储选型咨询

结论：完全不需要引入MongoDB实例，单PostgreSQL即可覆盖你当前及未来5年的所有需求，还能避免跨库事务的额外开发成本。 #

针对你担心的几个问题逐一说明：

• JSONB检索性能完全够用
  你未来最大用户规模才40万，就算按人均发布100条内容估算，总数据量也就4000万级别，这个量级下PostgreSQL的JSONB性能完全没有瓶颈。你只需要针对要检索的字段建对应索引即可：如果是JSONB内部固定要检索的键（比如标题、描述），可以直接对指定键建GIN索引，或是提前生成全文检索向量tsvector建索引，查询效率和普通结构化字段没有明显差距。

• 多字段检索、相关性排序能力PostgreSQL原生支持，不需要额外开发复杂逻辑
  你要的多字段短语匹配、按相关性得分排序的功能，PostgreSQL自带的全文检索功能完全可以实现，还支持给不同字段设置不同权重（比如标题权重高于描述，提升搜索合理性）。
  举个简单的使用示例：

-- 给标题、描述生成带权重的检索向量，建GIN索引
CREATE INDEX idx_post_fts ON posts USING GIN (
  setweight(to_tsvector('zhparser', coalesce(title, '')), 'A') ||
  setweight(to_tsvector('zhparser', coalesce(content->>'description', '')), 'B')
);

-- 查询时直接获取相关性得分排序
SELECT *, ts_rank(
  setweight(to_tsvector('zhparser', coalesce(title, '')), 'A') ||
  setweight(to_tsvector('zhparser', coalesce(content->>'description', '')), 'B'),
  to_tsquery('zhparser', '要搜索的关键词')
) AS rank
FROM posts
WHERE 
  setweight(to_tsvector('zhparser', coalesce(title, '')), 'A') ||
  setweight(to_tsvector('zhparser', coalesce(content->>'description', '')), 'B') @@ to_tsquery('zhparser', '要搜索的关键词')
ORDER BY rank DESC;

如果需要中文分词支持，只需要安装zhparser扩展即可，完全不需要依赖MongoDB或是额外部署Elasticsearch。

• 其他业务场景适配性更好
  带回复的评论结构你可以按需选择：要灵活就用JSONB存嵌套结构，要方便做分页、统计就用邻接表/闭包表的关系型结构存储；话题标签直接用数组字段或是JSONB数组存储，建GIN索引后查询特定标签的内容效率极高。所有操作都在同一个PostgreSQL实例内完成，天然支持ACID事务，根本不需要做额外的两阶段提交开发。

额外建议

当前阶段完全没必要做过度架构设计，等后面真的出现单PostgreSQL满足不了的检索需求（比如TB级别的全文检索、复杂的多维度聚合搜索），再考虑引入专门的检索组件也完全来得及，现在引入MongoDB除了增加开发、运维成本，没有任何实际收益。

内容的提问来源于stack exchange，提问作者Lahiru Udayanga