Cursor -> turbopuffer, cutting costs by 20x

turbopuffer is one of the few pieces of infrastructure we haven’t had to worry about as we’ve scaled. Since day one, turbopuffer has felt like they were part of our team.

Sualeh Asif, Co-founder and CTO

Why turbopuffer?

turbopuffer’s serverless architecture with unlimited namespaces was a natural fit for Cursor’s namespace-per-codebase use case. Active codebase namespaces are loaded into the memory/NVMe cache, and inactive codebase indexes fade into object storage.

This cold/warm set of tradeoffs was a perfect fit for Cursor to realize dramatic cost reduction without degrading performance. Unlimited namespaces mean the Cursor infrastructure team no longer has to manually balance codebase indexes to servers.

Results

Cursor migrated to turbopuffer in November 2023 and experienced:

1. 20x cost reduction
2. Unlimited namespaces in a fully serverless model; no more bin-packing codebase vector indexes to servers
3. Peak ingestion of 1M+ writes/second, for faster migrations and indexing

After switching our vector db to @turbopuffer, we're saving an order of magnitude in costs and dealing with far less complexity!

Aman Sanger, Co-founder

turbopuffer in Cursor

turbopuffer powers code retrieval features in Cursor to populate the context window with code searches when appropriate. In the example below, Cursor draws on turbopuffer to semantically search across the codebase.

Codebases opened in Cursor are chunked and embedded with Cursor’s own embedding model. Each (user_id, codebase) is a separate namespace in turbopuffer, and Cursor employs various mechanisms like copy_from_namespace to recycle embedding vectors between namespaces.