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