10 PostgreSQL 不只是关系库: 向量、全文检索与混合搜索
如果今天还把 PostgreSQL 只理解成“事务型关系数据库”，那已经有点落后了。它依然最擅长事务和结构化数据，但在实际工程里，越来越多团队开始把全文检索、向量检索和业务过滤组合在一起使用。PostgreSQL 的价值，恰恰在于它能把这些能力放进同一个数据边界中协同工作。
先不要急着问“能不能做向量”
更应该先问的是:
- 数据本来是不是主要就存放在 PostgreSQL
- 检索规模是否仍在单库可控范围
- 是否比起极致性能，更看重集成成本和工程一致性
- 查询是否需要和业务过滤、权限、状态字段强耦合
如果答案大多是“是”，那么在 PostgreSQL 里做检索通常很合理。
三种搜索能力分别解决什么问题
1. 全文检索
适合关键词匹配、词项相关度、结构化文本查询。它擅长回答“有没有这些词、这些词有多相关”。
2. 向量检索
适合语义相似性检索。它擅长回答“意思像不像”。
3. 混合搜索
适合真正的业务系统。它通常不是纯向量，也不是纯关键词，而是:
- 先用结构化条件过滤
- 再结合关键词与语义相似度召回
- 最后按业务规则排序
这才是 PostgreSQL 在实际业务里最有价值的地方。
在 PostgreSQL 中做搜索的优势
- 结构化数据和检索数据能放在一起管理
- 权限、租户、状态等过滤条件天然容易融合
- 事务一致性更容易保证
- 系统复杂度更低，不一定需要额外引入一整套搜索基础设施
对于很多中型系统来说，这些优势比“理论极限吞吐”更重要。
也要明确边界
下面这些场景，通常应该更慎重:
- 纯搜索型产品，数据规模极大
- 超低延迟要求
- 检索策略复杂到需要独立演进
- 召回和排序高度依赖专门搜索工程能力
PostgreSQL 的强项是“把检索能力和业务数据紧密结合”，不是替代所有专业搜索系统。
设计时最容易犯的几个错误
1. 把 embedding 当成普通字段随便存
应该明确:
- 向量维度
- 模型版本
- 生成时间
- 是否需要重建索引
否则后面模型升级时会非常痛苦。
2. 没有先做结构化过滤
很多搜索请求其实天然带条件，比如租户、状态、时间范围、分类。先过滤再做相似度检索，通常比全量盲搜更实用。
3. 过早追求复杂召回链路
专栏和项目初期，最稳的路径往往是:
- 先实现可工作的混合检索
- 再观察质量和成本
- 最后再决定是否拆出独立搜索系统
一个成熟的工程判断
不要问“PostgreSQL 能不能做搜索”，而要问“我的搜索问题有多少比例其实是业务数据问题”。如果答案很高，那么 PostgreSQL 往往值得成为搜索体系的一部分，甚至直接成为第一阶段的主战场。