How Simon Eskildsen Built TurboPuffer, the Vector DB Powering Cursor and Notion

Have you ever looked at your infrastructure costs and thought, "This can't be right"? That's exactly what happened when Simon Eskildsen discovered vector databases were so expensive that companies couldn't even launch features.

After spending nearly a decade at Shopify scaling databases to handle millions of requests per second, Simon left to help friends with their infrastructure challenges. What he found would change everything. Working with Readwise in late 2022, Simon discovered that building a recommendation engine with vector embeddings would cost around $20,000 per month, more than quadruple what Readwise was paying for their entire relational database.

The feature got shelved. But Simon couldn't let it go.

Key Takeaways

• TurboPuffer achieves up to 100x cost reduction compared to traditional vector databases by storing data on object storage like S3 at $0.02 per GB instead of in-memory at $2+ per GB
• Major companies like Cursor, Notion, and Linear have switched to TurboPuffer, with some seeing order of magnitude cost savings
• Simon built the first version alone over summer 2023 before launching publicly on October 4, 2023
• Cursor migrated their entire workload in just a few days and immediately saw costs drop 10x
• The company reached $1 million in ARR within a year of launch with just two founders
• TurboPuffer now operates profitably with only 17 people while powering billions of vectors

Table of Contents

1. The Problem: When Infrastructure Costs Kill Features
2. Simon's Background: Ten Years Scaling Shopify
3. The Summer of Obsession: Building TurboPuffer V1
4. First Customer: How Cursor Found TurboPuffer
5. The Notion Deal That Changed Everything
6. Why TurboPuffer Didn't Raise a Series A
7. The Six Reasons to Fundraise Framework
8. Building a Profitable Database Company
9. Lessons for Technical Founders

The Problem: When Infrastructure Costs Kill Features

In late 2022, Simon was helping Readwise scale their infrastructure ahead of launching Readwise Reader, a read-it-later app. The team wanted to build article recommendations using vector embeddings, but the economics didn't work. While Readwise paid around $5,000 monthly for their relational database, vector search on the same 100 million documents would have cost $20,000 per month or more.

This wasn't just expensive. It meant shelving a desired feature until costs came down.

For months, the problem gnawed at Simon. A promising feature, postponed solely due to infrastructure costs? Surely these exorbitant prices weren't rooted in some immutable law of physics.

As Simon dug deeper, painful memories surfaced from his early days on Shopify's infrastructure team. Search engine outages had been some of the worst incidents. The clusters were expensive, fragile, and constantly needed attention.

What if there was a better way?

Simon's Background: Ten Years Scaling Shopify

Simon joined Shopify in 2013 when the company had around 150-200 people and was handling just hundreds of requests per second. He moved from Denmark to Ottawa, Canada for what he thought would be a gap year position on the infrastructure team.

That "gap year" turned into nearly ten years.

During his time at Shopify, Simon and his team scaled the platform from 1,000 requests per second to over 1 million requests per second. He worked on virtually every aspect of the database layer, the persistent bottleneck when scaling infrastructure.

Simon led critical projects including the storefront rewrite for performance gains up to 10x faster, MySQL patches for resource usage tracking, and the Pods architecture for application-level sharding. He learned what it takes to keep a platform running while it grows exponentially.

By 2021, Simon felt ready for a change. After almost a decade in one place, he wanted to see infrastructure challenges in other companies. He left Shopify and spent the next two years doing what he called "angel engineering," working in three-month increments with startups like Replicate, Causal, Datafold, and Readwise.

It was during one of these consulting stints that he discovered the vector database problem.

The Summer of Obsession: Building TurboPuffer V1

In May 2023, a consulting agreement fell through. Simon was discussing his options with a friend, explaining how he thought you could build a search engine with completely different tradeoffs than existing solutions.

His friend told him: "You should just do it."

They spent that evening riffing on branding ideas. Simon wanted something that felt ASCII and retro for the website, but not too far into the uncanny valley. Looking at emojis on their phones, they found the pufferfish. No other connotations, perfect.

When their wives joined them, Simon's friend's wife suggested "TurboPuffer" in an Australian accent. Everyone agreed it just made them happy.

The fundamental insight was storage architecture. In 2022, production-grade vector databases relied on in-memory storage at $2+ per GB, not counting extra costs for durable disk storage. This was the most expensive way to store data.

But by leveraging object storage like S3 or GCS at around $0.02 per GB, with SSD caching at $0.1 per GB for frequently accessed data, you could achieve up to 100x cheaper storage for cold data and 6-20x cheaper for warm storage.

The tradeoff? Write latency would be higher, hundreds of milliseconds instead of microseconds. But for search applications, that was acceptable. When you're adding a new song to Spotify or a new product to Shopify, it's fine if it takes a moment to appear in search results.

Simon locked himself in to build. His wife was patient, though understandably a bit annoyed. Simon was completely consumed, thinking about the database from the moment he woke up until he went to bed. During dinners, he'd be running experiments to test different theories.

He did three complete rewrites that summer, testing every approach he could think of to ensure he'd found the best solution. He changed platforms, tried different indexing strategies, and refined the architecture.

On October 4, 2023, after four months of focused work, Simon launched what he claimed was the first truly serverless vector database, pricing it at $1 per month per million vectors and $4 per million queries, making it 10-70x cheaper than alternatives.

The launch post on X got nearly 400,000 views. People were interested.

First Customer: How Cursor Found TurboPuffer

Within days of launching, Simon received an email from a small San Francisco company. They were just six people, and they had a problem eerily similar to Readwise's situation.

They were spending six figures annually on vector search, but the per-user costs were unsustainable. If they were paying $5 per user for infrastructure while charging $20, the unit economics didn't work as they scaled.

The company was so busy dealing with outages that Simon struggled to get them on a call. When one of the co-founders finally emailed at 5:20 AM Eastern time on a Thursday, Simon happened to be awake and immediately jumped on a call.

After that conversation, Simon felt he needed to meet them in person. He flew to San Francisco, arriving on a Monday afternoon without telling them he'd made the trip specifically for them. He just said he was "in town" and could drop by.

When Simon showed up at their office, they were dealing with Postgres database issues. Simon spent the afternoon teaching them everything he knew about running Postgres at scale, helping them resolve the problems.

That consulting session must have convinced them he knew databases, because shortly after, they decided to migrate to TurboPuffer.

The company was Cursor.

Cursor moved everything in just a few days in November 2023 and immediately saw their costs drop 10x with great cold and warm latency. They started with a few billion vectors, one of the largest workloads in the world at the time.

As Cursor grew naturally, the cost-value mapping improved dramatically, and they started creating more vectors per user than before. Infrastructure costs were no longer a bottleneck to product decisions.

Meanwhile, Simon had reached out to Justin Li, who he considered the best engineer he'd worked with during his time at Shopify. Justin initially joined part-time, but within three or four days said he wanted to be all in. Justin became co-founder.

Their first bill from Cursor was 95% smaller than what Cursor had been paying before. And as Simon would discover from watching the dashboards, Cursor was just getting started on their explosive growth trajectory.

The Notion Deal That Changed Everything

While working intensely with Cursor throughout late 2023 and early 2024, Simon knew Notion would be a perfect fit for TurboPuffer's architecture. Through multiple introductions and five months of persistence, Notion finally reached out in early 2024.

The economics were holding them back on product features, and they wanted to explore alternatives.

When Simon joined the first call, there were six people from Notion in the room, and he was alone representing TurboPuffer. They bombarded him with technical questions about capabilities and performance.

Simon later learned that team members at Notion had independently sketched out what they thought the right architecture for their search needs would be, and it was essentially TurboPuffer's design.

Notion asked for a region in Oregon. Simon and Justin spun one up within a day. The proof-of-concept phase began.

Notion's workload involved more than 10 billion vectors across millions of namespaces, making it perfect for TurboPuffer's approach since only a subset of workspaces are active at once.

What happened during the POC became legendary inside TurboPuffer. Justin pulled engineering feats that went beyond anything Simon had seen in their eight years working together at Shopify.

One evening, the team returned from a small offsite in Quebec, Canada. Notion had finally ingested their first workload, but queries were taking 500 milliseconds when they needed under 100 milliseconds.

Justin found 300 milliseconds of optimization in the span of three hours that night, shipping PR after PR.

Another time, Notion asked if TurboPuffer could support a specific feature. Justin replied in Slack: "Yes, we can." Then he worked for 24 straight hours to build it and get it into Notion's hands.

Week after week, Justin demonstrated this level of commitment. Simon worked on pricing optimization to ensure TurboPuffer wouldn't lose money on the deal. Their second employee, Bojan, was completely rewriting TurboPuffer's core architecture. Morgan, their third hire, was building full-text search capabilities.

By summer 2024, it was getting close. On July 25th, the deal was nearly done, but Simon was racing to finish the billing system that would make the Notion relationship profitable.

His wife was seven days overdue with their first child.

Notion signed the contract on July 25, 2024. Simon invited Justin and their virtual CFO Mike for a small celebration in Ottawa, with Bojan and Morgan joining via video. Justin joked to Simon's wife that it would be funny if their daughter was born that day.

Everyone left. Justin and Simon hung out for another hour, and Simon cried a little from the intensity and relief of securing the deal.

Then Simon's wife came down and said she thought something was happening. Three or four hours later, their daughter was born.

After migrating to TurboPuffer, Notion saved millions of dollars and removed all per-user AI charges from their product. The usage pattern showed the clear power-law distribution that made object storage ideal—most data was rarely accessed.

Why TurboPuffer Didn't Raise a Series A

By late 2024, TurboPuffer had everything VCs look for in a Series A candidate. They had Cursor, Notion, Linear, and other major logos. Revenue was growing quickly. The team was small and efficient. Multiple funds would have written checks.

Simon turned them all down.

When asked why he didn't raise after these massive customer wins, Simon explained his framework of exactly six legitimate reasons to raise capital:

1. To prove product-market fit

This is what TurboPuffer did in January 2024. They raised just enough money from one investor, Lockheed, to fund R&D for the year. Simon and Justin told investors they would close shop by the end of 2024 if they hadn't found PMF. Everyone except Lockheed found that terrifying.

2. To fund growth

Once you have a proven way to turn dollars into more dollars through marketing and sales, you raise to accelerate growth. TurboPuffer still didn't have this motion nailed down in 2024, as most growth came inbound.

3. For ego

Also known as raising "because you can" or "because of momentum" or "because you got preempted." Simon was blunt: these aren't first-principle reasons to raise capital, which has real downsides like diluting employees and increasing strike prices.

4. For employee liquidity

To reward early employees who believed in the company with liquidity opportunities. TurboPuffer wasn't ready for this yet.

5. For trust and publicity

Raising from prestigious investors builds credibility, which can be especially important for database companies. However, TurboPuffer got lucky—Cursor went from relatively unknown to a massive brand in months, giving TurboPuffer amazing social proof without needing VC validation.

6. For strategic partnerships

Sometimes you raise because a VC will dramatically help your business through connections, or because getting an institutional investor on your cap table matters for a specific customer segment.

Simon's philosophy was clear: "If you are raising for any other reason than those six reasons, you are raising for reason number three, which is to fund ego."

TurboPuffer chose to stay profitable and focused rather than pursue vanity rounds. The constraint wasn't capital—it was finding enough world-class database engineers to hire.

The Six Reasons to Fundraise Framework

Simon's framework deserves deeper examination because it cuts through the typical founder confusion about when to raise capital.

Reason 1: To prove product-market fit

Raise enough to give yourself a clear runway to test your hypothesis. TurboPuffer raised enough for one year of R&D. They set a clear deadline: find PMF by end of 2024 or shut down. This created forcing functions and clarity.

Reason 2: To fund growth

This only makes sense after you have a repeatable, scalable channel where $1 in produces $2+ out. Without that proven motion, growth capital gets wasted on experiments. TurboPuffer's growth in 2024 came almost entirely inbound through technical content and word-of-mouth, not paid channels.

Reason 3: For ego

Simon was direct about this trap. Raising because you can, because you're getting inbound from VCs, because your competitor raised, or because you want the PR hit—none of these are good reasons. They come with real costs: dilution, higher option strike prices, time spent on fundraising instead of building.

Reason 4: For employee liquidity

This becomes important for companies that have been around longer and have early employees whose equity is largely illiquid. Secondary sales or tender offers can help retain key talent. TurboPuffer's team was too young for this.

Reason 5: For trust and publicity

Database companies especially benefit from credibility signals. If you're unknown and trying to convince enterprises to bet their infrastructure on you, a tier-one VC backing can help. But TurboPuffer lucked into better social proof by powering Cursor during their explosive growth phase.

Reason 6: For strategic partnerships

Sometimes you need a specific VC's network to unlock a customer segment. Or you need Disney on your cap table to sell to other movie studios. The strategic value needs to outweigh dilution costs.

The framework works because it forces discipline. Before every potential fundraise, ask: which of these six reasons applies? If none do strongly, don't raise.

Building a Profitable Database Company

As of October 2024, TurboPuffer operated with just 17 people while remaining profitable. This wasn't an accident—it was intentional strategy.

Simon believed deeply that building a large, independent database company required sustainable economics from the start. Database companies need years to reach their full potential, and profitability buys time and options.

The team's small size reflected hiring constraints, not capital constraints. Simon emphasized he was limited more by finding exceptional database engineers than by funding. TurboPuffer hosts over 1 trillion documents, handles over 10 million writes per second, and serves over 10,000 queries per second.

The customer base included not just Cursor and Notion, but also:

• Linear, which moved from Elasticsearch and PGVector to TurboPuffer for a more hands-free experience, viewing it as foundational infrastructure that enabled connecting more data to LLMs without operational overhead
• Superhuman, using TurboPuffer for intelligent email search and organization features, leveraging cost-effective storage to index years of email history
• Suno's radio feature and Dot's memory system by New Computer

TELUS, one of Canada's largest telecommunications companies, became TurboPuffer's second major enterprise customer in early 2024. An engineer at TELUS had seen TurboPuffer and believed enough in the product to bet his internal credibility on a startup.

Industry analysis in 2025 praised TurboPuffer's performance, low costs, high limits, and enterprise features without enterprise pricing.

Lessons for Technical Founders

Simon's journey from Shopify engineer to profitable database company founder offers several crucial lessons:

1. Overfit on one customer's problem first

Simon didn't start with a grand vision for revolutionizing vector databases. He saw Readwise couldn't afford to launch a feature they wanted, and he became obsessed with solving that specific problem. Only later did he realize dozens or hundreds of other companies had the same issue.

2. Architectural innovations come from constraint

The insight to use object storage came from understanding the acceptable tradeoffs for search workloads. Slower writes didn't matter when adding content to a search index, but massively cheaper storage changed the entire economic equation.

3. Trust your intuition over articulate advice

Simon emphasized that founders will encounter many articulate advisors and VCs with strong opinions. But if you truly have founder-market fit, you need to trust your gut. "You've got to just lean into the things that make your business and what you think is right weird. That's what makes your business unique."

4. Design decisions matter more than founders think

Simon and his designer friend Jørgen spent hundreds of hours on TurboPuffer's website and branding. The ASCII aesthetic, the pufferfish emoji, the clear pricing calculator—these elements communicated care about developer experience and helped TurboPuffer stand out in a crowded market.

5. Distribution through excellence, not marketing

TurboPuffer gained Cursor, Notion, and Linear without a sales team or marketing budget. They won through technical excellence, responsiveness, and making customers successful. Justin's 24-hour coding marathons during Notion's POC exemplified this approach.

6. Profitability buys options

By staying profitable from early on, TurboPuffer maintained control over its destiny. Simon could turn down funding offers that didn't align with his vision. He could wait to find exactly the right database engineers rather than hiring quickly to deploy capital.

7. Timing matters for database companies

Simon identified two key ingredients for any generational database company: a new workload that gives every company a reason to need your database, and a fundamentally new way to store data that challenges assumptions of existing players.

The new workload was connecting AI to enormous amounts of data. The new storage architecture was object storage with intelligent caching. These two ingredients only came together in 2022-2023.

Frequently Asked Questions

What is TurboPuffer and what does it do?

TurboPuffer is a serverless vector and full-text search database built from first principles on object storage. It's designed to be fast, approximately 10x cheaper than alternatives, and extremely scalable.

How much does TurboPuffer actually cost compared to alternatives?

TurboPuffer achieves up to 100x cheaper storage by using object storage at $0.02 per GB with SSD caching, compared to traditional in-memory storage at $2+ per GB. Pricing is $1 per month per million vectors and $4 per million queries.

Which companies use TurboPuffer?

Major adopters include Cursor, Notion, Linear, Superhuman, Suno, and New Computer. TurboPuffer powers over 1 trillion documents with over 10 million writes per second and serves over 10,000 queries per second.

How did Simon Eskildsen come up with the idea for TurboPuffer?

While consulting for Readwise in late 2022, Simon discovered that building article recommendations with vector embeddings would cost $20,000+ monthly, forcing them to shelve the feature. This economic constraint sparked months of thinking about how to make vector search more affordable.

Is TurboPuffer a bootstrapped company?

TurboPuffer is not fully bootstrapped. They raised a small amount (less than $1 million) from one investor in early 2024 to prove product-market fit, and they've operated profitably since with just 17 people.

What's Simon Eskildsen's background before TurboPuffer?

Simon spent nearly 10 years at Shopify from 2013-2021, where he worked on infrastructure and helped scale the platform from hundreds to over 1 million requests per second. After leaving, he spent two years consulting for startups on infrastructure challenges.

How long did it take Simon to build the first version of TurboPuffer?

Simon spent four months of focused work building TurboPuffer before launching it publicly on October 4, 2023. He did three complete rewrites during that period to find the best architecture.

What makes TurboPuffer's architecture different?

TurboPuffer decouples compute from storage, running search engines on separate nodes while using object storage as the source of truth. SSDs on nodes are only used for caching vectors, making it fundamentally more cost-effective than traditional search databases that store data and compute on the same machines.

How did TurboPuffer win the Cursor and Notion deals?

For Cursor, Simon flew to San Francisco and helped them fix Postgres issues, demonstrating database expertise before they migrated. For Notion, co-founder Justin Li worked multiple 24-hour coding sessions during the POC, including finding 300 milliseconds of latency optimization in three hours.

What advice does Simon have for technical founders?

Simon emphasizes trusting your intuition over articulate advice from VCs, leaning into what makes your business unique rather than following cookie-cutter playbooks, and only raising capital for one of six specific reasons: proving PMF, funding proven growth, employee liquidity, building trust, strategic partnerships, or ego (which he advises against).

Want More Founder Stories Like This?

This article is based on an episode from The Product Market Fit Show, where host Pablo Srugo interviews successful startup founders about their journeys from zero to PMF and beyond.

Listen to the full conversation with Simon Eskildsen to hear more about building TurboPuffer, landing Cursor and Notion, and finding true product-market fit.

🎧 Listen to the episode here →