RIP，向量数据库

原文 ↗ Hacker News 讨论 ↗

向量数据库越来越被视为不适合大多数真实检索任务的抽象，许多工程师更青睐传统 SQL 或搜索引擎，让向量搜索只是众多索引中的一种，与文本、元数据过滤和连接并列。评论者指出，把向量作为主存储布局会导致严重的写放大和复杂性，并将其与 Postgres 和 MySQL 的历史索引权衡相类比，主张让近似最近邻（ANN）索引指向稳定的文档 ID。总体趋势是转向“多模态”数据系统——ClickHouse、Postgres 扩展、Elasticsearch、Vespa、LanceDB 等——将向量搜索整合进现有数据库能力，而不是依赖独立的向量存储。

页面加载与性能

  • 一些用户一开始无法加载博客页面；另一些人则报告称，在服务器负载问题缓解后，页面加载很快。
  • 性能测量结果各不相同：有人看到响应迟缓、Pagespeed 评分一般，也有人报告 Lighthouse 指标非常出色、渲染近乎瞬时完成。
  • 对于缓慢到底是客户端问题还是服务器负载问题，大家意见不一；不少人指出带宽（例如 10G vs 1G）并不是瓶颈。

SQL/分析型数据库 vs. 专用向量数据库

  • 多位评论者认为，对于企业检索来说，向量“只是”现有 SQL 或搜索系统中的另一列和索引类型。
  • 他们列出的 SQL + 向量方案优势包括：更容易做连接、过滤、ACL、多租户隔离、元数据约束、时间过滤，以及避免同步单独向量存储的复杂性。
  • 文中提到的例子包括如今支持原生向量或向量 + 全文搜索组合的数据库和引擎。

索引设计以及与 Postgres/MySQL 的类比

  • 一个主要主题是：把 ANN 地址用作主键，在向量移动时会导致严重的写放大。
  • 评论者直接将其与历史上的 Postgres 与 MySQL 索引设计权衡进行类比（辅助索引指向行位置 vs. 主键）。
  • 共识是：让 ANN 索引指向稳定的文档 ID，并接受一次额外查找，往往更好，即使这意味着多一次跳转（可能到对象存储）。

“RIP 向量数据库”的解读

  • 一些人强调，被“淘汰”的是向量优先的存储布局，而不是向量搜索本身。
  • 他们指出，这实际上让 ANN 变成了辅助索引，使向量数据库与现有搜索引擎对齐——后者本来就会混合稠密、稀疏、词法和过滤查询。
  • 也有人认为这个标题主要是营销包装；核心观点其实是架构层面的。

自定义与嵌入式搜索系统

  • 一些从业者表示，通过构建定制或嵌入式系统（例如带自定义 IVF 索引的 SQLite、GPU 加速的索引构建），在本地或单用户工具中能取得更好的效果。
  • 也有人提醒不要为每个用例都重新造数据库，强调 SQLite/parquet 等成熟格式以及现有工具链的价值。

LLM 编写的评论与版务担忧

  • 这里明显能看到对 HN 上 LLM 生成评论的焦虑、对“水军”的指责，以及对 astroturfing 和观点操纵的担心。
  • 有人讨论像邀请制论坛那样的门槛注册作为部分缓解手段，但其长期有效性存在争议。
  • 也有人认为频繁指责“这看起来像 AI”正在成为一种低成本的回避，而不是实质性批评。

AI 热潮、语气与怀疑态度

  • 少数评论者将这篇帖子斥为“AI 垃圾内容”或过度炒作，批评其营销语气和标题。
  • 另一些人则为其技术深度辩护，坚持文章是手写的，并指出如今被归因于 LLM 的一些文风习惯其实早在它们出现之前就已经存在。
  • 更广泛地说，评论者观察到 AI 热潮周期的波动性，并在尘埃落定之际更倾向于选择成熟的 SQL 系统。