What does Turbopuffer do?

Turbopuffer is a search engine built on object storage like AWS S3, offering vector search for AI applications at 10x lower cost by pulling data into RAM only when needed. The company reportedly crossed $100M in ARR, validating its early bet on separating storage and compute, a strategy pioneered by Snowflake and others in cloud infrastructure.

What does Turbopuffer do? And what's going on in the category formerly known as vector databases? The TL;DR Turbopuffer is a search engine built on top of object storage like AWS https://technically.dev/posts/aws-for-the-rest-of-us S3 . AI applications need to quickly search through lots of unstructured data text + embeddings https://technically.dev/universe/embeddings . Cursor searches through your codebase, Notion AI searches through your documents. In the early days of AI applications, most vector search options like vector databases https://technically.dev/universe/vector- database:database stored data on RAM to ensure fast query https://technically.dev/universe/query times. This turned out to be quite expensive. Turbopuffer offers a search engine on data stored in object storage like AWS S3 , and only pulls data into RAM when it’s needed. They claim this makes it 10x cheaper while still being fast. Competitors like Pinecone and Elastic https://technically.dev/posts/what-does-elastic-do also followed suit with “ serverless https://technically.dev/universe/server ” vector search tooling. Search is one of the most competitive spaces in AI infrastructure https://technically.dev/universe/infrastructure . Turbopuffer reportedly crossed $100M in ARR recently, so their early bet on object storage is paying off. Their story is one of an obsessive focus on knowing what can be done with the tools cloud https://technically.dev/universe/cloud providers like AWS + GCP have on offer. It’s a tale as old as 2006. Separation of storage and compute In 2006, AWS launched https://press.aboutamazon.com/2006/3/amazon-web-services-launches a simple product without fanfare. It let developers store + retrieve unlimited numbers of files, and it promised not to lose track of them: All software does is basically manipulate files, and S3 Simple Storage Service was a bottomless filing cabinet. Renting it was much cheaper than buying your own filing cabinet of merely moderate size. AWS launched https://aws.amazon.com/about-aws/whats-new/2006/08/24/announcing-amazon-elastic-compute-cloud-amazon-ec2---beta/ S3’s soulmate, EC2 Elastic Compute Cloud in a similarly low-energy way in August of 2006. It let you rent as many servers as you needed, whenever you needed them. This pairing the foundation of the Cloud made developers rather thirsty. By separating compute from storage as separate cloud services https://technically.dev/posts/what-are-microservices , you could reimagine stodgy, ubiquitous infrastructure like databases. The creators of Snowflake https://technically.dev/posts/what-does-snowflake-do were two of those developers, and the analytics https://technically.dev/universe/analytics warehouse was a ripe first target. As Snowflake https://technically.dev/posts/what-does-snowflake-do co-founder Benoit Dageville put it https://www.youtube.com/watch?v=XqzSjya54BU : I always said that as older software guys we were at the mercy of hardware and its resources. The cloud was a game changer for analytic workloads that has lots of peaks and troughs in usage. It really needed that elasticity the cloud offered. Him and his co-founder Thierry Cruanes left Oracle and started Snowflake in 2012, which today has an ~$80B market cap. Larry Ellison had no comment. These two AWS launches from 2006 unlocked an untold number of novel data infrastructure companies to be built. Analytics + machine learning https://technically.dev/universe/machine-learning : Databricks https://technically.dev/posts/what-does-databricks-do , Snowflake’s nemesis for data engineering workloadsTransactional databases: Neon, the transactional database acquired by Databricks Streaming: WarpStream, the real-time event streaming service acquired by their competitor Kafka https://technically.dev/universe/kafka Search: Turbopuffer All have succeeded by rebuilding foundational data tooling on top of object storage like S3. Enter vector search AI agents make analytics workloads look quaint by comparison. Just the vector search piece is a perfect storm of how to run up a cloud bill: Embeddings are big . If a chunk of text is 1KB, an embedding vector representing the meaning of that text could be 6KB. Agents search more than humans . Way more. If you watch a coding agent work, it runs tons of searches. I usually only search “Oprah net worth” once a week. Agents produce more vectors . More~~slop~~code + documents means the search index grows faster than it would if it was just people making stuff. Search engines like Algolia https://technically.dev/posts/what-does-algolia-do or Elastic at this time were designed for a person searching in a search box on a website. They needed instant feedback, so data was stored in RAM. High cost was a tradeoff for low latency. For agents using vector search, the tradeoff needed to be different. High cost was untenable, so the solution would be to trade a little latency. 💡 Food for thought There’s debate as to whether agents need vector search, or whether they can just use keyword search the “grep” tool to hunt-and-peck their way through your codebase or documents. Claude Code famously currently doesn’t actually index your codebase into a searchable vector index. This is a pretty silly debate: not every use case is the same.