Dify 在高负载场景下主要面临以下 PostgreSQL 性能瓶颈:
- DB 连接池压力:单次 Chat 请求可能触发数百甚至上千次数据库访问,加上 Worker 进程的知识库索引构建和 Trace 追踪等持续写入,极易打满连接池。
- 存储膨胀严重:运行时日志(工作流执行明细、会话历史、消息记录等)占据 DB 存储空间的 95% 以上,且包含大量长文本(工具输出、模型上下文等)。
- 慢查询频发:访问频率最高和慢查询最多的 SQL 模式中,绝大多数与运行日志的读写相关。
- 垂直扩展困难:PG 扩容依赖升配,升级规格往往伴随主备切换导致的连接闪断或维护窗口,难以无感扩容。
- 分析能力不足:控制台仅支持有限关键词检索,难以对历史会话进行多维分析和精细化运营。
根本原因是数据特征与存储引擎的错配——工作流记录具有终态不可变、泛结构化、高吞吐时序写入等日志特征,不适合用关系型数据库长期承载。