Q：LangGraph Checkpoint 为啥不使用mysql呢？mysql不支持向量化？

A：不是 MySQL 不支持向量化，而是在 LangGraph Checkpoint 场景下，PostgreSQL 比 MySQL 更适配，且两者在向量能力上的差距主要体现在生态而非底层支持：

1. LangGraph Checkpoint 场景：PGSQL vs MySQL 核心差异

Checkpoint 存的是 Agent 状态数据（序列化的轨迹、历史），不是向量数据。PGSQL 胜出的原因是：

• JSON 能力更强：PGSQL 的 jsonb 类型支持索引、嵌套查询，对 LangGraph 复杂的状态对象序列化/反序列化更友好；MySQL 的 JSON 类型索引支持较弱，查询复杂结构时性能差。
• 事务与并发更稳：PGSQL 的 MVCC 机制对多用户会话的状态隔离更可靠，国内云厂商托管版的高可用配置（主从、读写分离）更成熟，适配 Agent 多租户场景。

2. 向量能力：PGSQL 生态更成熟，MySQL 也能支持

• PGSQL：通过 pgvector 插件可原生支持向量存储和相似度检索，能一站式搞定 Checkpoint 状态 + 向量数据，适合 RAG + Agent 融合场景（比如把检索结果也存在 Checkpoint 里）。
• MySQL：8.0.34+ 版本支持 VECTOR 类型，也能做向量检索，但插件生态不如 pgvector 完善，国内生产环境案例较少。

3. 国内不用 MySQL 做 Checkpoint 的核心原因

国内企业选 PGSQL 更多是 历史选型惯性 + 云厂商支持：

• 阿里云、腾讯云的托管 PGSQL 对 jsonb、pgvector 的优化更到位，运维成本低；
• 早期 LangGraph 生态示例多基于 PGSQL，国内开发者直接复用更省心。

简单说：MySQL 能做 Checkpoint，也支持向量，但 PGSQL 综合适配性更好。