我创有一个 AI 交流群，如果你想学习 Agent 项目落地或者想交流 Agent 技术的的可以加我v
yunmz777，
Stack Overflow 的开发者调查里，有一组变化挺值得注意。
2018 年，使用 PostgreSQL 的受访者占比大约是 33%；到了 2024 年，这个数字已经接近 49%。在 2025 年的调查中，它又连续第三年拿到了数据库类别里"最想使用"和"使用后最想继续使用"的最高排名。
当然，这不是全球数据库市场份额，不同年份的受访者也不完全相同。但至少能看出来：PostgreSQL 不只是被讨论得多，确实有越来越多开发者在用它。
问题是，数据库已经这么多了，为什么偏偏是它？
我觉得，得从现在开发一个应用到底需要存什么说起。
做一个 RAG，才发现要存的远不止向量
假设要做一个 AI 客服。
用户提问，系统去知识库检索相关资料，再交给模型回答。刚开始看，好像找个向量数据库就够了。
但继续往下做，问题就来了。
这份资料属于哪个客户？是否已经过期？用户有没有权限查看？检索出来的内容，能不能找到对应的原文？
这些信息都得保存，而且查询时还要一起考虑。
pgvector 的官方 README 展示的就是这样一种能力：给 PostgreSQL 增加向量类型和相似度检索，同时保留原来的 SQL 查询方式，可以加过滤条件，也可以关联其他表。
于是，文档、文本片段、所属客户、版本和向量，就可以放在同一套数据库里管理。
这时候，PostgreSQL 吸引人的地方就不只是"能存向量"了。
而是你原本就需要一个业务数据库，现在它还能承担知识库的存储与检索，不一定非得再维护一套系统。
当然，pgvector 不会自动帮你把 PDF 解析好、切好片段、生成向量。它负责的是存储和检索，不是一整套 RAG。
JSONB 解决的，也是项目里很常见的麻烦
还有一种情况，做业务时经常碰到：有些字段很固定，有些字段总在变。
比如商品。
名称、价格、所属品牌可以设计成固定列。但充电器要记录功率，耳机要记录降噪模式，衣服又要记录材质，很难给它们套上完全相同的属性结构。
PostgreSQL 的 JSON Types 文档明确提到，关系型数据和 JSON 可以互相配合。JSONB 不只是把一段 JSON 原样塞进去，还支持按内部字段查询，并为适合的查询建立索引。
所以，可以把稳定的信息放在普通列里，把变化较多的属性放进 JSONB。
对于 AI 应用，模型返回的结构化结果、工具参数、文档附加信息，也可以采用类似的设计。
不是说这样就能替代所有文档数据库，而是需求刚出现时，不必立刻换一套存储方案。
不过，用户编号、订单金额这些重要字段，还是应该认真设计。JSONB 方便，不代表整张表只留一个 JSON 字段就是好设计。
Agent 的状态和记忆，也需要数据库
做 Agent 时，注意力很容易都放在模型和工具调用上。
但任务跑到一半，等用户审核怎么办？服务重启后，之前执行到哪里了？用户上次交代过的偏好，下次还要不要记得？
这些事情都需要持久化。
LangGraph 的官方记忆文档里，就提供了 PostgreSQL 的接入方式：PostgresSaver 用来保存执行检查点，PostgresStore 可以保存跨会话使用的记忆数据。
这里不是 PostgreSQL 自己会"记忆"，而是框架把状态和需要保留的信息写进数据库，再按规则读取和恢复。
这样一来，一个 Agent 应用里的用户信息、知识库和工作流状态，都有机会用同一套数据库基础设施来管理。
对团队来说，这种方便很实际。少接入一个系统，就少考虑一份连接配置、备份和故障排查。
为什么它总能多做一点？
看到这里，可能会觉得：PostgreSQL 怎么什么都能碰一碰？
一个重要原因是，它允许通过扩展增加新的数据处理能力。
pgvector 是一个例子。PostGIS 和 TimescaleDB 的项目介绍也明确说明了各自与 PostgreSQL 的关系：前者扩展地理空间能力，可以处理位置、距离和区域关系；后者面向时间序列和事件数据。
所以，PostgreSQL 并不是等 AI 火了，才突然开始支持别的需求。向量检索只是这个扩展生态里比较受关注的一部分。
这也解释了为什么只用"性能好""事务可靠"来介绍它，总觉得没说到点上。
这些基础当然重要，但开发者选型时还会考虑：今天用它做业务，过几个月加搜索、加知识库，是不是还能接着用？
能继续沿用已有的数据和工具，往往比重新接入一套系统更省事。
Supabase 又让更多人接触到了它
还有一个不能忽略的因素，是使用门槛。
Supabase 的数据库文档说得很明确：每个项目背后都是一个完整的 PostgreSQL 数据库，认证、存储、实时能力等围绕这个基础提供。
所以，一个人开始用 Supabase，可能只是想赶紧把登录、数据保存和接口做出来，但实际上已经在使用 PostgreSQL 了。
相比先自己安装数据库、配置连接、安排备份，这类平台缩短了从"想做个东西"到"真的跑起来"的距离。
从这个角度看，PostgreSQL 的吸引力不只来自数据库本身，也来自围绕它搭建的产品和工具。
那以后选 PostgreSQL 就行了？
也没必要走到另一个极端。
一个已经稳定运行的 MySQL 项目，没有理由只因为 PostgreSQL 热门就迁移。向量检索、数据分析这些需求，也应该根据自己的数据量和查询方式测试，不能只看"支持"两个字。
我更愿意把 PostgreSQL 理解成一个适用范围比较宽的选择。
普通业务可以先做起来，遇到动态数据有 JSONB，增加 RAG 可以考虑 pgvector，做 Agent 也有现成的持久化接入方案。它们不是选型时必须全部用上的功能，却给后面的需求留了余地。
很多时候，开发者并没有打算找一个"最强数据库"。
只是希望产品多加几个功能以后，不用把已经搭好的东西重新折腾一遍。