How TurboPuffer Cut Vector DB Costs 95% and Won Cursor

What if the reason AI features don't ship isn't the model — it's the database bill? Simon Eskildsen discovered that vector storage was so expensive that companies shelved entire product ideas. He built TurboPuffer to make it 100x cheaper, then flew uninvited to Cursor's office to prove it.

Key Facts

• Cost reduction for Cursor: First bill was 95% smaller than their previous six-figure monthly spend (Simon Eskildsen)
• Team size at profitability: 17 people, profitable, powering Cursor, Notion, and Linear (Simon Eskildsen)
• S3 storage cost advantage: ~$0.02/GB on S3 vs. $2–5/GB in RAM — two orders of magnitude cheaper (Simon Eskildsen)
• PMF moment: Notion signed on July 25, 2024 — the same day Simon's daughter was born (Simon Eskildsen)
• Initial traction channel: Launch post on X reached nearly 400,000 views with no paid promotion (Simon Eskildsen)

Why Vector Databases Were Too Expensive to Use

Vector embeddings are larger than the original data they represent, making storage costs prohibitive. When Simon priced a recommendation engine for Readwise, the bill came to ~$30K/month — too expensive to justify. This pent-up demand convinced him a cheaper architecture was worth building.

Simon's founding insight came while doing contract infrastructure work for Readwise, a bootstrapped reading app. He built a working recommendation engine using vectors — numerical coordinates that represent content similarity — but when he ran the numbers on putting it in production, the cost was around $30,000 per month on existing providers. The feature got shelved. Not because the technology didn't work, but because the unit economics made it impossible to earn a return.

This is the core insight behind TurboPuffer: the problem wasn't the AI models. It was the database layer underneath them. As Simon explains, a vector embedding (the coordinate that represents a piece of text) is actually larger than the original text itself. That means storage costs compound fast — and for most companies, the math simply doesn't work.

Simon recognized that S3, Amazon's object storage, costs roughly $0.02 per gigabyte — compared to $2–5 per gigabyte in RAM. That's a true 100x cost difference. The tradeoff: writes to S3 take hundreds of milliseconds instead of microseconds. For checkout systems, that's unacceptable. For search — where you're okay if a new product takes 200ms to appear in results — it's a perfectly reasonable compromise.

"There's got to be thousands, if not tens of thousands of these use cases. I just couldn't stop thinking about that." — Simon Eskildsen

"If you put data in memory, it costs maybe two to five dollars per gigabyte. If you put it in an S3 bucket, it costs about two cents per gigabyte. A true two order of magnitude cheaper." — Simon Eskildsen

How Simon Built TurboPuffer Alone — and Launched It on X

Simon locked himself in for the summer of 2023, rewrote the database three times, and launched on X with a nearly 400,000-view post. He had no co-founder, no customers, and an egg avatar — but deep technical credibility from a decade scaling Shopify's infrastructure.

From May to October 2023, Simon built TurboPuffer alone. He describes the period as 'completely all-consuming' — thinking about the problem from the moment he woke up until he went to sleep, running experiments during dinner, and doing three full rewrites to test every architectural approach. His wife, by his own admission, was 'very patient, but also a little bit annoyed.'

On October 4, 2023, he posted the launch on X. He had accumulated a modest following through his writing on database scaling and napkin math — quick calculations showing what computers can actually do at various layers of the stack. That credibility translated: the post reached nearly 400,000 views. No paid distribution. No launch partner. Just a technically precise post landing in front of the right audience.

The name came from a late-night Airbnb session in Copenhagen with his designer friend Jørgen, whose wife coined 'TurboPuffer' in an Australian accent. The brand strategy was deliberate: monospace aesthetic, all key database questions answered on the homepage, nothing that made it look like a sneaker company. Design as a signal of engineering rigor.

"I was thinking about this from the second I woke up until the second I went to bed. I was truly captivated and I felt that if I didn't do it, someone else was going to do it." — Simon Eskildsen

• Three full rewrites during the summer of 2023 to find the best architecture
• Launched October 4, 2023 with ~400K views on a single X post
• Website designed to answer: what does it do, what are the tradeoffs, what does it cost
• Brand built to signal DevEx care and engineering credibility simultaneously

How TurboPuffer Won Cursor: Fly Uninvited, Fix Their Postgres

After an inbound email from a six-person San Francisco startup about crushing vector costs, Simon flew to their office unannounced. He helped them debug a Postgres issue on arrival, built trust through technical depth, and they migrated their entire workload within a week — cutting their bill by 95%.

The email came from a tiny company spending six figures on vector infrastructure with unit economics that didn't work. Getting them on a call was nearly impossible — one co-founder emailed at 5:20 AM Eastern (2:20 AM his time) asking if Simon was free. Simon was up. They talked. And then Simon made a decision most founders wouldn't: he flew to San Francisco without telling them why.

'I showed up on a Monday afternoon,' Simon recalls. 'They were having problems with their Postgres database. And so I just tried to teach them everything that I knew about running Postgres at scale.' That hands-on credibility — a decade of Shopify infrastructure experience applied in real time — convinced the team that Simon knew what he was doing. They started the migration.

That company was Cursor. Within a week, they had migrated billions of vectors. Their first TurboPuffer bill was 95% lower than what they'd been paying. Simon and co-founder Justin worked closely with the Cursor team through their hypergrowth, and one moment stood out: Cursor co-founder Sualeh told Simon that TurboPuffer was 'one of the only things that we just don't worry about' as they scaled.

"I need to go meet them and so I flew to San Francisco. I showed up on a Monday afternoon, and they were having problems with their Postgres database. That must have convinced them that maybe I knew a little bit about databases." — Simon Eskildsen

"Their first bill was ninety-five percent smaller than their six-figure bill that they had before." — Simon Eskildsen

Closing Notion: 24-Hour Sprints and a Baby Born on Signing Day

TurboPuffer won Notion through months of POC work, with co-founder Justin pulling back-to-back all-nighters to hit performance targets. Notion signed on July 25, 2024. Hours later, Simon's daughter was born.

Notion came through a combination of outbound persistence and investor connections. Multiple introductions were ignored before someone finally took a call. Then months passed with no commitment. The Notion team, Simon later learned, had independently sketched out what the right architecture for their search should look like — and it matched TurboPuffer's approach almost exactly.

The POC was intense. When Notion ingested their first workload, query latency was around 500ms. They needed under 100ms. Justin found 300ms of improvements in three hours that night, shipping pull requests from a team offsite in Quebec. On another occasion, Notion asked if TurboPuffer could support a specific capability. Justin replied in Slack: yes. Then worked for 24 straight hours to make it true.

Simon signed the Notion deal while simultaneously building the billing system to ensure the company wouldn't lose money on the workload. Notion's team asked directly: 'Are you going to lose money on this?' — a sign they were genuinely worried about TurboPuffer's survival. Notion signed on July 25. Justin said to Simon's very pregnant wife, 'Wouldn't it be funny if your daughter was born today?' Hours later, she was.

"Justin just told them in Slack, yes, we can. And then worked like I've never seen before for the next 24 hours to get it in their hands. When people talk about forcing something or willing something into existence, this is one of the first things that I think of." — Simon Eskildsen

"I cried a little bit that day. It was just like, we'd worked so hard on this and Justin in particular." — Simon Eskildsen

The 6 Reasons to Raise — and Why TurboPuffer Said No to $30M

Simon declined a Series A because none of his six legitimate fundraising criteria applied. His framework: raise only to prove PMF, fund proven growth, hire constrained by talent not capital, provide employee liquidity, build trust/credibility, or forge strategic partnerships. Everything else is ego.

After signing Notion, TurboPuffer had everything a Series A pitch deck needs: marquee logos, rapid growth, a clear technical moat. Most founders would have raised $30M immediately. Simon didn't. His reasoning: raising capital has real costs — dilution, higher strike prices on options, pressure to grow in ways that may not suit the business. Those costs need to be justified by specific, first-principles reasons.

Simon's six reasons to raise are: (1) fund R&D to reach PMF; (2) fund proven growth once you can turn dollars into revenue predictably; (3) ego/momentum — which he explicitly calls illegitimate; (4) employee liquidity; (5) trust and credibility with customers; (6) strategic partnerships. For TurboPuffer post-Notion, reasons two and five were the most plausible candidates. But growth was still primarily inbound, so there was no proven engine to pour capital into. And Cursor's brand had grown so fast that credibility wasn't a bottleneck.

The deeper constraint isn't money. 'If you find me thirty database engineers of the caliber of the ones that I already have, then yeah, then we need to raise,' Simon says. 'I'm constrained in finding those people and getting them to join TurboPuffer more so than I am on capital.' At 17 people, profitable, with Cursor, Notion, and Linear as customers, TurboPuffer is building what Simon calls 'an enduring, large, independent business.'

"If you are raising for any other reason than those six reasons, you are raising at reason number three, which is to fund ego." — Simon Eskildsen

"I'm constrained in finding those people and getting them to join TurboPuffer more so than I am on capital. And by the way, these engineers want equity." — Simon Eskildsen

• Raise to prove PMF: only if you'd close up if you don't hit it by a deadline
• Raise to fund growth: only if you have a proven, repeatable customer acquisition engine
• Raise for ego/momentum: never a legitimate reason
• Raise for employee liquidity, credibility, or strategic partnerships: situational
• Talent scarcity, not capital scarcity, is TurboPuffer's actual constraint

S3-Based vs. RAM-Based Vector Storage