站在 600亿 Cursor 背后的“疯子” —— 这家向量数据库初创公司，把性能榨干到了极致

今天要说的这家数据库公司，是一个站在Cursor背后的隐形冠军。

如果单纯地去讲向量数据库公司，可能大家都会没有兴趣，表示向量数据库过时了、烂大街了。

但这家向量数据库公司却是Cursor规模化代码检索的基石。

没有它，Cursor就可能无法很好地管理上千万用户的代码空间、过万亿份文档。

这家公司就是Turbopuffer，https://turbopuffer.com，已获得Thrive Capital、Lachy Groom等顶级风投的种子轮融资，客户名单包含了Anthropic、Notion、Cursor和Atlassian等领军企业。

其团队规模不大但技术密度极高，团队部分人员信息如下：

当大家都在卷高性能服务器、卷内存向量检索时，这家公司却走了一条极端的路线：Stateless（无状态）+ Object Storage（对象存储）。而正是这种架构，使得Cursor可以无限制地创建名字空间，极大地降低了其基础设施的运维负担。

对象存储优先的技术架构

Turbopuffer在向量数据库领域的核心创新在于其“对象存储优先”的架构设计，如下图。这种设计打破了传统数据库依赖昂贵内存或本地SSD作为主存储的范式。

• 核心理念：以对象存储作为单一事实来源
• 三层分级缓存架构 Memory->SSD->Object Storage

为了克服对象存储高达100ms以上的网络延迟，Turbopuffer构建了精密的缓存体系，使热数据的查询速度能够比肩内存数据库

• 写入流与一致性保证

Turbopuffer使用预写日志（WAL）来确保一致性。每一次成功返回的写入都意味着数据已持久化到对象存储中的命名空间前缀下。

SPFresh索引与性能优化

主流向量数据库采用的是HNSW算法，其搜索过程涉及大量的随机内存跳转。这个过程在本地内存中只需纳秒级，但在对象存储中，每一次跳转都可能触发一次100ms以上的网络往返。

Turbopuffer没有采用HNSW，转而选择了更适合对象存储特性的SPFresh算法。受其启发，Turbopuffer采用基于质心的ANN搜索技术：

• 聚类机制： 向量被组织成具有语义关联的簇（Cluster），每个簇由一个“质心”向量代表。
• 查询优化： 查询时，系统首先将查询向量与质心进行对比，筛选出最相关的簇，然后仅下载并搜索这些簇内的数据。这种方法将对象存储的往返次数压缩到了3-4次，极大地优化了冷启动查询的性能 。
• 动态平衡： 索引支持增量更新，簇会随着数据的插入和删除自动拆分与合并，无需像传统索引那样定期重建 。

在ANN v3版本中，Turbopuffer引入了RaBitQ算法，将全精度向量（f16/f32）压缩为每维度仅1比特的二进制表示 。

• 存储压缩： 实现16倍以上的空间节省，允许更多数据驻留在高性能缓存层。
• 计算加速： 配合现代CPU的AVX-512指令集，位计数操作可以在数个时钟周期内完成。这成功将瓶颈从带宽限制转移到了CPU计算能力上，使得单索引支持1000亿个向量成为可能 。

规模化代码检索的基石

作为Turbopuffer最具代表性的客户，Cursor展示了该技术在大规模生产环境中的爆发力。

• 解决“命名空间爆炸”问题 Cursor在Turbopuffer上管理着超过8000万个命名空间，总文档数超过1万亿。每一个用户的每一个项目库都需要独立的索引环境。传统的向量数据库对索引数量有严格限制，Turbopuffer的Serverless架构允许Cursor无限制地创建命名空间，极大地降低了基础设施的运维负担。
• 20倍的成本消减 在迁移到Turbopuffer之前，代码库语义搜索的成本是Cursor增长的主要阻碍。通过利用S3的廉价存储，Cursor实现了95%的成本降幅 。这种经济效益不仅提升了公司的利润空间，还使其能够为用户提供更深度的代码上下文分析，而无需额外收费。
• 索引回收和秒级更新 由于大部分代码更改是增量的，Cursor会指纹化文件树，找到相似的既有索引并快速复刻新命名空间 （利用Turbopuffer的copy_from_namespace功能来处理代码库的克隆和分支），这使得中等规模项目的首次查询时间从约8秒缩短到了525毫秒，99分位延迟从4小时缩短到了21秒。

Turbopuffer的未来路线图

Turbopuffer并未止步于现有的性能优势，其“Up Next”计划展示了向更复杂数据处理领域进军的野心。

• 命名空间钉选 (Namespace Pinning)： 针对有持续高并发需求的应用，提供预留计算资源，保证缓存永远处于“热状态” 。
• 命名空间分支 (Branching)： 这将支持更复杂的开发流，例如允许AI Agent在不同的代码库分支上进行实验性搜索而不影响主索引 。
• 多向量列支持： 同一文档可以关联多个向量（例如一个是摘要向量，一个是细节代码块向量），提升检索的多维精度 。
• 稀疏向量支持： 进一步强化其在传统搜索与语义搜索结合部（如SPLADE等模型）的统治力 。
• 嵌套属性与聚合函数： 随着Group By、Distinct、Min/Max等功能的引入，Turbopuffer正在逐渐演变成一个具备向量搜索能力的轻量级分析型数据库 。

随着企业对数据主权的要求日益提高，Turbopuffer的BYOC模式配合CMEK正在成为行业标准 。这允许像Notion、Linear这样的公司既能享受Serverless的弹性，又能满足最严苛的数据安全审计要求。

小结与展望

• Turbopuffer小结

1. 架构优势：对象存储优先的架构彻底解决了大规模向量数据的存储成本问题。通过精密的Rust实现和三层缓存，成功将廉价存储的经济性与内存级性能相结合。
2. 工程导向： 避开了复杂的HNSW算法，选择了更适合云原生环境的SPFresh。这种从第一性原理出发的决策，使其在超大规模（万亿级）应用中表现出更强的稳定性。
3. 场景契合： 极其契合AI Agent、代码助手等需要大量逻辑隔离命名空间（Multi-tenancy）的场景，解决了传统数据库的扩展性瓶颈。

• 展望

可以预见，向量数据库将不再是一个独立的孤岛，其正从“功能验证期”向“生产效率期”转型。正如Turbopuffer正在做的，将全文搜索、复杂过滤、流式写入和低成本持久化整合进一个统一的、Serverless的API中，将成为AI基础设施演进的必然方向。

Turbopuffer不仅为Cursor提供了强大的动力，更为整个AI生态系统提供了一个可参考的范本：高效且极具经济竞争力的数字大脑底座。