PostgreSQL 18 JSONB 增加能取代 MongoDB 吗?

2025 年 2 月 24 日
 jinyan01
6308 次点击
所在节点    PostgreSQL
31 条回复
8PCSIZ7tmy4x9xFJ
2025 年 2 月 24 日
PostgreSQL 18 在新版本中加入了许多有趣的新功能,比如对 JSONB 的增强支持、对全文搜索的优化、以及更强大的扩展能力等,的确使得 PostgreSQL 在一些应用场景下更具竞争力。不过,能否完全取代 MongoDB ,还是要看具体的使用场景。

PostgreSQL 18 的新功能亮点
JSONB 和文档存储增强:PostgreSQL 18 加强了对 JSONB 数据类型的支持,提供了更强的索引优化和查询性能,对于需要存储非结构化数据或半结构化数据的应用,能够提供类似 MongoDB 的功能。

全文搜索:PostgreSQL 在全文搜索的表现也有所提升,尤其在复杂查询和多字段匹配方面。虽然 MongoDB 在搜索引擎方面的支持也不错,但 PostgreSQL 通过扩展(如 pg_trgm 和 tsvector )能够实现更强的文本搜索能力。

聚合与扩展性:PostgreSQL 提供了比 MongoDB 更强大的聚合功能,尤其在数据分析领域,PostgreSQL 可以执行复杂的 SQL 查询,支持事务、外键约束等,适合需要强一致性的场景。

扩展支持:PostgreSQL 的扩展支持非常强大,可以通过各种插件增强数据库的功能,甚至可以结合 PostGIS 执行空间数据查询等。而 MongoDB 则主要专注于文档存储和灵活的键值数据存储。

PostgreSQL 与 MongoDB 的对比
数据模型差异:MongoDB 是一个面向文档的 NoSQL 数据库,天然支持 JSON 格式的数据结构,适合高并发、分布式的应用,且无模式的设计非常灵活。PostgreSQL 在 JSONB 类型上虽然有所增强,但本质上还是关系型数据库,更适合复杂的关系型数据结构和事务。

水平扩展:MongoDB 在水平扩展( sharding )方面有天然的优势,特别是在处理大规模、分布式数据时,MongoDB 更容易做到自动分片和扩展。虽然 PostgreSQL 在某些扩展方面也支持分布式部署,但在水平扩展的能力上,MongoDB 更加成熟。

事务支持:PostgreSQL 提供了强一致性的事务支持,适用于需要高数据一致性和复杂查询的场景。MongoDB 在事务支持上有改进,但在一些场景下仍然不如 PostgreSQL 可靠。

结论
虽然 PostgreSQL 18 通过增强对 JSONB 和全文搜索的支持,能在一定程度上取代 MongoDB 处理半结构化数据的能力,但如果你需要处理大规模分布式数据、自动扩展、以及更灵活的数据模式,MongoDB 依然在这些方面表现更好。

因此,是否能完全取代 MongoDB ,取决于你的应用场景。如果是需要强一致性、复杂关系数据和复杂查询的系统,PostgreSQL 可能是更好的选择。如果是需要处理大规模分布式文档数据和灵活存储,MongoDB 可能更合适。
knightgao2
2025 年 2 月 24 日
@xiaogu 你号没了
knightgao2
2025 年 2 月 24 日
好好说话
我们希望能够在 V2EX 建立和倡导一种好好说话的氛围。

请尽量描述事实,而非观点。
如果你要反驳什么,请反驳那个主要的要点,而不是一些旁枝末节。
我们建立这里的主要目的是为了讨论技术细节。不要在 V2EX 讨论任何国家的政治。
如果你要说的话是为了伤害别人,那么请不要说。如果你要说的话,你有预感在将来你会想要删掉它,那你最好现在就不要说。
在一个公共空间的公共讨论中,我们应该关注的,是自己能够在这些讨论中提供什么样的建设性增益,而不是那些纯粹个人的感受。比如当大家在讨论一件你不了解的东西时,你没有必要去回复一条“不明觉厉”。
请不要把 AI 生成的回复,当作你自己的回复,发到这里。
回忆一下你看过的电影里的那些正面角色的说话方式——把一件事情好好陈述出来,没有冷笑,没有嘲讽,没有反问,就只是好好说话而已。
qW7bo2FbzbC0
2025 年 2 月 24 日
我觉得还是专库专用,瑞士军刀虽然比较百搭,但是职业工作的话,一般会选择专业套装
privil
2025 年 2 月 24 日
日常销号系列。话说 FerretDB 也 2.0 了

MongoDB 的开源替代方案 FerretDB 发布 2.0 版本

https://mp.weixin.qq.com/s/h-USEDmzAWXh6aZVdXuXpA
happyxhw101
2025 年 2 月 24 日
主要还是取决于你都场景和规模
如果是单机的话,我觉得 pg 可以代替 mongodb ,但是如果考虑分布式,那么就不一定了
laikicka
2025 年 2 月 24 日
@Livid #2 ai 回复
codingmiao
2025 年 2 月 24 日
MongoDB 早就名誉扫地了吧,牛逼吹上天,坑一大堆。话说有哪些场景是必须要 JSON 格式才能去支撑的呀,业务成熟起来后,都会变成明确的字段结构,又回到传统关系型库。
jinyan01
2025 年 2 月 24 日
@qW7bo2FbzbC0 维护太多种数据库比较麻烦,如果 pg json 速度可以,我个人倾向直接用 pg
dayeye2006199
2025 年 2 月 24 日
没啥太复杂的需求,只是希望用 json 的结构体+部分简单基于 json 的查询,PG 是完全可以的。
PG 功能很多,全文搜索,向量查询,如果需求不太复杂,一个数据库可以胜任好多不同的任务
roundgis
2025 年 2 月 24 日
微软贡献了一个 documentdb 的插件 ferretdb2.0 就是基于这个插件的 据说大幅度提升兼容性和性能

Ferretdb 之前的版本我试用过 修改奇慢无比 查询勉强可用。

Pg jsondb 和 mongodb 不是一回事 只是看起来像而已。如果真的是差不多那 ferretdb 还至于花这么多功夫么

微软更没有必要搞插件了
roundgis
2025 年 2 月 24 日
@codingmiao 用的人还是不少的 django 最近都开始支持 mongodb 了
viking602
2025 年 2 月 24 日
@xiaogu 请不要把 AI 生成的回复,当作你自己的回复,发到这里
viking602
2025 年 2 月 24 日
@livid 一楼 AI
sockpuppet9527
2025 年 2 月 24 日
不太清楚 MongoDB , 但对于 PG 的 JSONB 来说的话,取部分 JSON 数据是不下推的。意味着如果你本身单条 JSON 数据很大,又存在取部分 JSON Key 的场景的话,做 seq scan 依然会把完整 JSON 读出来。当然你可以建对应的 GIN Index 来改善这一点。

还有另外一点 PG 取 JSONB 的话,可能需要将你的 sql 改为 [jsonpath Accessors]( https://www.postgresql.org/docs/current/datatype-json.html#DATATYPE-JSONPATH) 来取部分数据
qW7bo2FbzbC0
2025 年 2 月 24 日
@lxue 很简单的,我直接用 MySQL JSON 列。复杂的放 MongoDB
C02TobNClov1Dz56
2025 年 2 月 24 日
我更倾向于专门的工具做专门的事, 如果你的系统没有特别复杂, 倒是可以用 pg 自带的 jsonb, 但是如果需要做 json 相关的操作很多, 还是建议用 MongoDB
Livid
2025 年 2 月 24 日
@laikick
@viking602

谢谢,那个用 AI 回复的账号已经被彻底 ban 。
musi
2025 年 2 月 24 日
mysql 不也支持简单的 json 么,这个 JSONB 和 mysql 的比有什么优势?
niubiman
2025 年 2 月 24 日
@musi pgsql 钟的 jsonb 和 json 是存储方式不同, jsonb 是采用二进制存储,json 是文本存储, jsonb 写入性能差一些, 读取性能高一些, jsonb 反之, 我没怎么用过 mysql 的 json, 我才差异可能类似吧

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1113761

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX