← #802

DeepSQL：可自托管的 Postgres 与 MySQL DBA 智能体

文章摘要

DeepSQL 自称是「你数据库的大脑」，是一个由 AI 驱动的数据库管理方案，持续不断地优化和监控数据系统。作者 Venkat 是 Stayflexi（YC）的创始人、CMU 计算机系毕业，曾在 Oracle 查询引擎团队工作并持有核心数据库方向的专利。

按他的介绍，DeepSQL 最初是一个内部工具，用来阻止他们自己的数据库（生产环境服务 13000 多家酒店）变成瓶颈，效果足够好之后决定对外发布。产品定位是「像资深 DBA 和数据工程师那样操作数据库的 AI 智能体」，宣称的四项能力是：修复慢查询（他们把自家数据库开销降低了 4 倍）；治理数据库膨胀（在氛围编程搭出来的环境里阻止不必要的 schema 变更）；生成 BI 看板（他们据此砍掉了 Tableau、Retool 和 Appsmith 的开销）；以及安全能力（可以对内部员工屏蔽敏感和 PII 数据的访问权限，同时让组织内所有人都能与数据库交互）。

工作机制上分几层：首先 DeepSQL 从你的代码库、规则和查询日志中学习你的数据与关系；其次智能体有 20 个后台任务持续监控 schema 变更和性能瓶颈，力求在问题出现前给出方案（作者强调 schema 膨胀问题是不可逆的）；「DeepSQL Brain」提供 CLI 和 MCP 两种接口，可以直接对接 Claude、Codex 和 Cursor；每日推送一份数据库健康报告（digest）；团队成员可以通过 Web UI、CLI、MCP 或 Slack 任意一种入口接入。

支持的数据库是 PostgreSQL 和 MySQL，特别支持只读副本和 VPC 对等连接，使用只读凭证。部署方面强调自托管，一条 curl 命令即可在 Linux 系统、EC2 实例或容器上完成安装，官方称约 15 分钟搞定；三步流程为安装、配置（添加数据库连接和公司业务知识）、启用。配置项包括用自然英语教它业务规则、指向慢查询日志（pg_stat_statements 或 MySQL 慢日志）、以及维持只读的数据库访问权限。安全上宣称系统完全运行在用户自己的基础设施内，附带基于角色的访问控制、查询策略和审计日志。定价描述为「免费开始」，但页面上没有具体分层。

HN 评论精华

venkat971（作者） 首先给产品做了个定位澄清：「DeepSQL 不是替代你的 DBA，而是给你的 DBA 超能力。在我们组织里，当我们要决定是否招一个 DBA 时，我们选择了做 DeepSQL，让我们的资深工程师能像资深 DBA 那样处理数据库任务。」
evanelias 提出了本帖最有价值的质疑，围绕官网上「削减数据库成本 40%」这句话：「这个数字从哪来的？感觉完全是随口编的。」作者回应说他们自己的数据库总开销降了 3 倍多，从每月 9000 美元降到 3000，元凶是索引没生效、日志表快速膨胀和 schema 膨胀；另外砍掉 Retool 和 Appsmith 的许可证又省了 2000 美元；他们还与 6 家跑在 Aurora Postgres 上的 YC 公司合作，梳理了工作负载的低效之处——索引过多（有些案例里几乎每一列都建了索引），而过度索引会显著提高写入的 I/O 操作数，这种隐性成本对 Aurora 这类全托管服务来说极其巨大。evanelias 并不买账，把批评说得更透彻：「我的意思是，这个数字对每个用户来说都完全不同，取决于他们在数据库相关基础设施上做过多少糟糕决策。有些用户可能省 99%，有些几乎省不了，对吧？那为什么这里写 40%？」他说自己会立刻不信任一个声称精确 40% 节省的新产品——「甚至不是『最多 40%』或『超过 40%』（那样仍然误导，但没这么怪），而是精确的 40%，还放在首页第二行，没有任何支撑链接或信息。」他还追问「Retool 和 Appsmith 又不是数据库专用工具，为什么要算进节省里？」并指出如果这套节省数学是基于犯了极糟糕索引错误的极早期创业公司，那只会进一步降低他的信任。作者最终的回应很干脆：「把那个指标删掉了。我们的目标是用案例讲一个有说服力的故事，但你在很多维度上都说对了，对许多已经优化过的场景来说这个数字毫无意义。」
docheinestages 指出了信任层面的核心问题：落地页上没有 GitHub 链接，尽管写着「可自托管」，他真心以为这是闭源的。「我很怀疑首次使用的用户会信任一个随机工具、用一条 curl 命令就授予它数据库级别的访问权限。」作者承认这是很好的反馈，解释做成可自托管是为了让数据不离开客户场地，代码还没开源但很可能很快走这个方向。pella 随后在帖子里三次贴出了 github.com/DeepSQLAI/deepsql-self-host 这个仓库链接，而 shinryuu 检查后简短地下了结论：「不是开源。」mdasen 也表达了同样的困惑：「这是开源工具吗？是要付费的吗？网站真的没告诉我该期待什么。」作者回复说不是开源，前几个安装的用户提供 3 个月免费和免费的端到端配置咨询服务，之后定价将基于 AI token 消耗量加某种标准月费（他们还在摸索定价的甜蜜点）。
quard8 做了本帖最有杀伤力的一次尽调——他去读了 install.sh 文件，从里面找到这样一段提示文字：这次安装使用的是 DeepSQL 共享的托管 Azure OpenAI key，所以你的 schema 和查询会通过 DeepSQL 的共享 LLM 资源来处理。他还指出这个东西需要 Docker。作者确认了这一点：「是的。目前我们捆绑自己的 key，以保持 DeepSQL 智能体性能的一致性。我们很快会解除这个 key 捆绑，对企业部署我们可能会允许 BYOK（自带 key）。」edoceo 立刻追问了那个所有人都在想的问题：「那是不是意味着我的 schema 和数据被发送到你们的 OpenAI 智能体？」pbgcp2026 的评价更不留情：「这只说明他们中间没有真正的 DBA，只有氛围编程的人。」这段交流与产品「自托管所以数据不出场地」的核心卖点形成了直接矛盾，是全帖信息量最大的一处。
shenli3514 提出了竞品对比的问题：这产品很有意思，但和其他 DBA 工具比如何？市面上有很多基于「规则 + 统计」修复慢查询的工具。作者的回答是 DeepSQL 不需要任何预定义规则和统计，也不需要 DBA 来操作它——它是个自主智能体，会学习你的业务上下文、schema、join 关系，并构建出一整套心智地图（就像一个刚加入你团队的 DBA），他们称之为「DeepSQL brain 初始化阶段」；初始化完成后，它会审视所有慢查询工作负载，给出关于索引、物化视图等的综合建议。他强调其他 DBA 工具往往一次只看一条查询，而如果逐条优化就容易过度建索引。他还说 DeepSQL 能理解部署类型的差异——Postgres 单机部署与 Aurora Postgres 差别很大，成本因素完全不同，其他工具可能忽略这些因素，因此需要训练有素的 DBA 才能使用。shenli3514 继续追问：「我认为大多数慢查询用合适的工具、靠简单规则就能识别和修复，比如 Percona 的 pt-query-digest。你们做过任何关于工具准确率的基准测试吗？」作者答说他们与 pganalyze 这类行业标准工具做过交叉验证，多数工具都是孤立地分析工作负载，没有持续评估和跨轮次的上下文传递。他给了一个具体例子来说明差别：同一条看板查询对客户 A 跑 2 秒，对客户 B 要跑 50 秒——这里的问题是数据聚簇、以及不同 join key 的分布倾斜等多种因素；如果只看这条查询本身来修，很可能做出错误决定（大概是建个索引），而全局性的决策在这里应该是分区。
opwizardx 提了个直击要害的问题：「这和一个能访问 Oracle 文档的 Claude Code 有什么区别？」作者的回答是：Claude 不会去做频繁的 schema 漂移变更追踪、数据关系梳理、因 PII 泄露而阻断查询执行、关键列的基数计算……以及另外 20 项让它有效地像一个训练有素的 DBA 那样工作的参数。「这全是关于如何给智能体做 harness（约束框架），而我们的 harness 可以配合 Claude 或其他编码智能体来执行高效的 DBA 任务。」他举例说他们的安全 harness 会阻止敏感数据被查询，且能按用户级别强制执行——在组织层面围绕 Claude 构建和维护这样的 harness 是需要投入的。
bosky101 给出了一个关于商业模式的犀利观察：「感觉大家在修好了索引、拿到一次大额节省之后就会流失。不过还是祝你一切顺利。」作者回应说优化查询和 schema 监控只是 DeepSQL 的一个方面，它内置了 BI 服务器、以及安全与策略强制模块（决定谁能读什么数据），这些都可以接入日常业务和数据查询工作流。
vector_spaces 要求作者展开讲讲「砍掉 Tableau、Retool、Appsmith 开销」这条：你是说 DeepSQL 能做出让 Tableau 之类变得多余的 BI 看板？说的是业务团队用的分析看板，还是后端团队用的数据库运维看板？是用户提示智能体去做，还是它自己推断需要什么看板然后建出来？作者说 DeepSQL 有内置的 BI 看板服务器——你可以让智能体基于已连接的数据源构建任何 BI 看板，可供内部团队使用，也可以把带密码保护的看板链接分享给客户，就像分享 Retool 链接那样。
that_dba_guy 问它是否帮忙做上下文管理或所谓的 MemoryBank 配置，作者答说有内置存储层（Postgres 加 PGVector）。malamz 给了正面评价：「在一个可自托管的方案里把后台查询优化和 PII 脱敏结合起来，对小型工程团队来说是个非常扎实的组合。」
整体来看，这场讨论呈现出 Show HN 上一个相当典型的模式：产品思路（把 DBA 工作流封装成有约束的智能体、并强调只读接入与自托管）获得了一定认可，但营销数字的可信度、「自托管」与「共享 LLM key」之间的矛盾、以及闭源却要求数据库级访问权限这三点，构成了社区最主要的信任障碍。作者的应对相当坦诚——当场删掉了有问题的营销指标，并承认了 key 捆绑的现状，这在一定程度上挽回了讨论的气氛。