Retrieval After RAG: Hybrid Search, Agents, and Database Design — Simon Hørup Eskildsen of Turbopuffer
Most important take away
Turbopuffer is positioning itself as the search engine for unstructured data in the AI era, built on a fundamentally different storage architecture (all-in on NVMe SSDs and object storage) that existing databases cannot easily replicate. Simon argues we are in a once-every-15-years moment where a new workload (connecting massive data to AI), a new storage architecture, and the need to implement every query plan converge to create the conditions for a generational database company.
Chapter Summaries
Simon’s Background and Danish Roots
Simon grew up in Denmark and left at 18 to work at Shopify in Canada. He credits Danish culture’s “ruthless pragmatism” and focus on aesthetics as formative influences. He joins a lineage of legendary Danish programmers including Bjarne Stroustrup (C++), Rasmus Lerdorf (PHP), and Anders Hejlsberg (TypeScript/C#).
A Decade at Shopify Scaling Databases
Simon spent nearly a decade at Shopify on the infrastructure team, primarily focused on keeping the site up under massive scale — sometimes handling a million requests per second during flash sales. The hardest database to scale was self-hosted Elasticsearch, which was aggravating to operate and held back projects.
What Turbopuffer Is
Turbopuffer is a search engine specialized in full-text search and vector search — the system that holds the world’s knowledge in “full fidelity and truth” as the complement to LLM weights which compress reasoning but cannot hold all knowledge. It is the search layer that connects data to AI.
Three Conditions for Building a Generational Database Company
Simon outlines three conditions that align roughly every 15 years: (1) A new workload that means every company will have data in your database — connecting large amounts of data to AI. (2) A new storage architecture predecessors cannot easily adopt — going all-in on NVMe SSDs and object storage with no consensus layer. (3) Over time, implementing every query plan because users expect to ask any question once their data is in your database.
Radical Transparency with Investors
Simon told his lead investor that if Turbopuffer did not have product-market fit by year’s end, he would return all the money. His philosophy: “When I don’t know how to play a game, I just play with open cards.”
Summary
Actionable Insights
- The “15-year database cycle” framework: When evaluating infrastructure startups or deciding what to build, look for the convergence of (1) a new universal workload, (2) a new storage architecture that incumbents cannot easily adopt, and (3) the need to eventually support every query pattern.
- Go all-in on object storage for simplicity: Turbopuffer’s architecture has no consensus layer and stores everything in object storage. You could turn off every server and lose no data. This radically simplifies operations and is a pattern worth adopting for new data systems.
- Hybrid search (full-text + vector) is the current best practice: Pure vector search has limitations. Combining full-text search with vector search yields better retrieval results for AI/RAG applications. Invest in hybrid search rather than relying on embeddings alone.
- Elasticsearch’s pain points remain an opportunity: If you are self-hosting Elasticsearch, the operational burden is real. Consider newer purpose-built alternatives (Turbopuffer, Typesense, Meilisearch) especially for AI-connected workloads.
Career Advice
- Radical honesty as a founder strategy: Simon told investors he would return their money if the product didn’t find PMF. “Play with open cards” built trust rather than destroying it. Transparency with stakeholders is a differentiator.
- Danish culture’s “ruthless pragmatism” — focus on what works, not what’s impressive — is a transferable mindset for engineering careers.