Building: Gergely Orosz × Simon Eskildsen

In PowerPoint, a shape can link to another slide. Connect enough shapes and slides, and a presentation becomes a game: each click moves the player into another state. That was Simon Eskildsen’s entry into programming. In conversation with Gergely Orosz, author of The Pragmatic Engineer, the Turbopuffer founder starts with those increasingly convoluted games, joking about how quickly the possibilities escalated.

FrontPage came next. Its promise was that building a website would not require becoming a front-end developer. Then someone opened one of Simon’s sites in Firefox instead of Internet Explorer, and the layout fell apart. An accidental click into FrontPage’s HTML view exposed the machinery underneath. He began borrowing snippets to change the cursor, moved to Dreamweaver, and eventually wanted pages that could generate themselves dynamically. That led to PHP.

He exhausted the programming advice he could find before learning English. Four years of World of Warcraft supplied an unexpected prerequisite for going further: English. Looking back, he wonders how different that path would have been with an LLM that could explain programming without that language barrier. Instead, learning English opened a much larger technical web, and he began taking programming jobs during high school.

An internet friend who lived in Australia and competed on an International Olympiad in Informatics team suggested that Simon might find a team to apply to as well. Simon found its website and encountered problems very different from HTML and PHP. His illustrative example is to assign M packages, each with specified dimensions, among N trucks while optimizing the arrangement. The point of his NP-completeness shorthand is the difficulty of finding optimal solutions efficiently as problems grow; it does not mean that individual instances cannot be solved. Competitive programming gave him practice turning a loosely familiar situation into an algorithmic problem.

Shopify found Simon through an article, rather than through his competition results. After dropping and breaking his iPhone, he returned to a Nokia brick phone. He wrote about calling people again and recovering his sense of direction. In his account, the article briefly reached Hacker News, The New York Times featured it, and a Shopify recruiter connected the dots. The company apparently had not realized he was still in high school.

Invited to interview in Ottawa, he first had to establish what Ottawa was. Walking into Shopify felt right. He finished high school, moved to Canada, and joined in 2013, initially imagining a one-year gap before university.

Not having studied computer science made him insecure, but IOI had already taught him that he could sit with a paper long enough to understand it. At Shopify, he wrote down unfamiliar terms during the day and studied them that evening. If somebody mentioned TCP, he assumed they understood the three-way handshake, how TLS sat above it, and what the exchange looked like in Wireshark. He later realized that assumption was too generous, but it gave his self-education considerable depth. Soon he no longer wanted to leave the work he had found.

That impulse to peel back layers is now something he looks for when interviewing engineers. While still working on product, he sat beside infrastructure engineers at lunch and asked about their work. Even terminology became a reason to investigate: why is a reverse proxy reverse, or an inverted index inverted? The naming jokes recur later, but the underlying habit is serious—an abstraction invites a look underneath it.

On Shopify’s infrastructure team around 2013–2014, Simon helped containerize systems as Docker emerged. Simon recalls Shopify growing roughly 120–140% year over year. Preparing for Black Friday meant forecasting demand and ordering physical hardware in advance, while also making the software handle the next peak. Application bottlenecks repeatedly led him to the boundary between Rails and the databases. Much of the work there involved orchestration rather than modifying database internals.

His boss Camilo’s shorthand was that you cannot cache writes: a read cache does not remove the underlying requirement to persist incoming changes. Eventually the write workload must move beyond one shard. Simon joined around Shopify’s sharding transition and recalls a cutover about a week before Black Friday. Subsequent work expanded into multiple data centers and untangled a large shared Redis instance that had become a catch-all key-value store. When it failed, the team discovered how little they understood about its dependencies.

A dependency outage should have an explicitly designed scope. If the session store fails, the entire storefront should not automatically disappear with it. The team split apart the shared Redis responsibilities and built a matrix: for each service and failed component, what behavior should remain available? Writing down that expected degradation exposed the next problem—how to test the failures through the real application stack.

Simon’s first fault-injection experiment attached GDB to the application process and closed the file descriptor connected to the database. This forced failure through the connection-handling layers instead of replacing them with mocks. It uncovered substantial Rails issues, but the approach never shipped in CI. He then built Toxiproxy: a proxy placed between the application and its database connection.

Toxiproxy operates at the TCP layer; Simon corrects his initial layer-seven description to layer four. Its control API lets a test make a connection slow or unavailable while the application continues using its real database driver. Although he also mentions later layer-seven additions, the mechanism established here is transport-level fault injection. The driver’s recovery behavior becomes part of the test, rather than something a mock silently bypasses.

Orosz sketches a block that takes a database dependency down while fetching a page or exercising checkout. In Ruby, the documented indexed proxy selection and .down block express that pattern. With the application’s session connection routed through a proxy named sessions, an illustrative storefront availability check is:

require "toxiproxy"
require "net/http"

storefront = URI("http://localhost:3000/")

Toxiproxy[:sessions].down do
  response = Net::HTTP.get_response(storefront)
  raise "Storefront unavailable: #{response.code}" unless response.code == "200"
end

The assertion represents one cell in the failure matrix: losing sessions must not make this public page unavailable. Other cells need their own expected behavior.

Orosz describes tens of issues exposed across Rails and the MySQL driver. Production outages are poor opportunities to investigate those details: everyone is trying to restore the database, rather than studying how the application could have behaved better without it. Repeatable faults turn that emergency into a development exercise. Simon says the resulting tests worked well and believes Shopify still runs them in CI, though he does not confirm their current deployment.

The planned gap year became eight years at Shopify, from 2013 to 2021. Simon left because he wanted a different environment in which to learn. His work had ranged across caching, database scaling, multiple data centers, and traffic spikes from Kardashian product launches. Simon says the storefront rewrite he undertook with future co-founder Justine powered almost all storefront traffic eighteen months after they began. He left without a fixed next venture, but with a continuing project: Napkin Math.

Napkin Math collects hardware latency, bandwidth, and cost estimates: DRAM throughput, NVMe and EBS bandwidth, S3 round trips, memory prices, and differences between Spot pricing and longer commitments. Simon describes roughly fifty reference values, a Rust script to generate measurements, and flashcards to keep the numbers available in his head. His examples include memory at approximately $2 per GB and object storage at $0.02 per GB; the reference table labels these as monthly estimates, rather than current provider quotes.

The project grew out of infrastructure reviews. A team would benchmark database A, find it slow, and propose database B. Simon wanted to understand why A was slow before accepting the replacement. For a three-term search, he would estimate the matching document lists, the bytes that must be read, and the work required to intersect those lists. In his illustrative search calculation, an assumed multicore DRAM bandwidth of 100 GB/s suggests about 10 ms of work, against a reported 10-second benchmark. That gap is a question, not a verdict: either the model is missing something or the benchmark is measuring something unexpected.

For example, a supposedly simple query might fan out across a hundred nodes. Its P99 latency would then reflect distributed coordination and slow responders, not just local list intersection. The same reasoning applies to a B-tree: estimate pages visited and the cost of random reads, then compare that model with the observed query. A discrepancy points toward a query plan, a database bug, a disk problem, or an incorrect assumption. A benchmark tells you what happened; a cost model gives you something to investigate.

That method also catches errors in the mental model. Simon once reasoned that if each durable write needed its own fsync, database write throughput should equal the number of sync operations the disk could complete:

Simon recalls observing about 10,000 writes per second on a small MySQL machine, despite an initial estimate of 1,000 writes per second based on one 1 ms fsync per write. The machine was doing more work than his model allowed.

The missing mechanism was batching. Multiple writes can share a synchronization operation, so writes per second need not equal fsync calls per second. Finding that explanation took roughly a day of pre-LLM investigation: BPF traces, unexpectedly large writes, source-code reading, and a detailed MySQL article. His joke that the internet runs on small towns in Bavaria pays tribute to the obscure expert writing that finally makes a system understandable.

Three experiences converged into Turbopuffer. First came an unsatisfying search project at Shopify. Simon leaves the vendor unnamed, but describes a traditional search system that was difficult to operate, lacked a query planner in his account, and repeatedly failed to match his hardware estimates. Reading its source did not consistently explain the discrepancies. Second, Napkin Math had given him a strong sense of what a machine should be able to do.

Third came what he called Angel Engineering: working inside friends’ companies for vested equity rather than merely investing money. After ChatGPT appeared in 2022, one of those companies wanted to connect documents to AI. The early context windows were small enough that retrieval quickly became necessary; the speakers describe them in kilobytes, without identifying a model or establishing a token limit.

At Readwise, Simon built a recommendation prototype that was surprisingly revealing. While testing on a co-founder’s feed—with permission, he stresses—the recommendations led him to infer that the co-founder’s wife was pregnant. The feature worked well enough to justify calculating what it would cost to offer it to everyone.

Simon estimated that deploying the Readwise recommendation feature to all users would cost $30,000 per month, compared with roughly $5,000 per month for its other infrastructure at the time. For a bootstrapped company, the feature needed to earn enough to cover that cost and leave a gross margin. It did not meet that test, so they did not ship it. Simon returned to work such as tuning Postgres autovacuum, but could not stop wondering why storing the vectors had to be so expensive.

The alternative began as a question: could the vectors live in S3, clustered and arranged into files carefully enough to support useful search? Simon spent the summer of 2023 trying to make the latency work. Cheap, durable storage was available; the challenge was organizing the computation around its access costs.

Simon cites approximately 200 ms P99 latency for fetching a 256 or 512 KB S3 object. That is his design estimate; the discussion does not specify a region, concurrency level, or measurement method. Tail latency matters because a search stage often requests several objects in parallel. More requests mean more opportunities to encounter a slow response. A tree traversal adds another problem: the next level may depend on the previous fetch finishing. Root, intermediate nodes, and leaves can each introduce another object-store wait. Minimizing sequential round trips therefore matters more than making one small local computation faster.

By July 2023 he had something working end to end. After roughly two rewrites, he released it in October. It was still a solo curiosity project, not the execution of a venture-funded company plan. He took the basic ideas he needed from log-structured merge-tree literature and deliberately kept the implementation small.

The initial search procedure was concrete:

1. Cluster the vectors and write the clusters into files—literally cluster one, cluster two, and cluster three in his description.
2. Store the centroids separately, giving each cluster a representative vector.
3. Fetch the centroids for a query and identify the nearest ones.
4. Fetch the n closest clusters to obtain the candidate vectors for the search.

Some adjacent clusters were merged into shared files to control request costs and performance. The essential structure was already enough to test whether object-storage search could work.

For caching, Simon used software he already knew: an nginx reverse proxy in front of S3. It cached the objects without requiring a custom cache implementation. His extensive nginx Lua experience helped, although invalidation was decidedly direct—reverse-engineer nginx’s cache directory layout, shell out to xargs, and remove files. The first release ran on a single server inside tmux.

Orosz first encountered Turbopuffer while investigating Cursor’s infrastructure. He had assumed Cursor was one of several early customers. Simon corrects him: Cursor was the first. The contact came after a Twitter launch intended to answer whether anyone cared enough for him to keep working on the project. At that point it ran on an eight-core GCP node; he intended to block production adoption until he had set it up properly across multiple machines.

The launch pitch was a million vectors for a dollar. That historical offer was monthly storage pricing, with queries charged separately, as clarified in the company’s technical retrospective. Simon remembers the cheapest working alternative costing perhaps a hundred dollars per million, but does not identify it or give comparable billing conditions. The small deployment did preserve a non-negotiable durability invariant: writes went directly to objects, so shutting down every VM would not lose the committed data.

For a coding product, the storage arrangement matched the workload. An inactive codebase could remain in object storage; opening it would bring the active data into memory, where subsequent queries could run quickly. The cache would follow usage rather than requiring every stored vector to occupy DRAM continuously.

Simon imagines Cursor’s founders arriving at this same design over dinner, but explicitly says he does not know whether that conversation happened or whether they considered building it themselves. What he does establish is that Turbopuffer matched a problem they wanted solved.

Simon flew from Canada to Cursor’s San Francisco office. On arrival, he found a Postgres problem under discussion and suggested setting up pganalyze. His diagnosis centered on insufficient autovacuum and unnecessary heap access. The precise PostgreSQL distinction is an index-only scan: ordinary index scans already fetch heap rows, while index-only scans can avoid those fetches when visibility information permits it. Helping investigate the existing database gave Cursor a practical reason to trust the person proposing a new one.

By then Justine had joined as co-founder. Her first change replaced the nginx proxy cache with a direct file-based cache. Cursor decided that evening to migrate and completed the move over roughly one or two weeks. Simon reports that Cursor’s first Turbopuffer bill was 95% lower than its last bill from the previous vendor. When Orosz identifies that vendor as Aurora, Simon corrects him: this saving was not against Postgres; the replaced vendor remains unnamed.

Orosz says reliability was a principal motivation for Cursor and recounts Sualeh’s warning against betting a business on a tiny infrastructure supplier—with an exception for Turbopuffer. The apparent risk became more understandable after Simon showed up, helped with a real problem, and brought years of operating Shopify to the relationship. Trust came from demonstrated competence and direct cooperation.

Turbopuffer’s enthusiasm for CPUs produced an unusual encounter at NVIDIA. Presenting to Jensen Huang and company leadership about potential partnership opportunities, Simon joked that Turbopuffer could pivot into vapes if the database business failed. In Simon’s retelling, Jensen replied, “Judging by your slide, maybe you should.” Simon then asked whether Jensen vaped, prompting a teammate to relay the exchange to the company.

The team had warned him not to say the C word—CPUs. He nevertheless kept praising them: plentiful machines, SIMD, and AVX-512 were attractive ingredients for Turbopuffer’s workload. The anecdote ends with Jensen taking an interest, rather than with an announced GPU migration.

But CPU availability was no longer as easy as that pitch suggested. Simon connects the pressure to reinforcement learning environments that execute real tools. Teaching a model to search, run grep, or use Bash requires CPUs on which those operations actually happen. Deployed agents also perform general-purpose work. As applications expand into domains such as CAD, more environments are needed to teach and evaluate those capabilities, feeding demand back into training.

Turbopuffer needs NVMe SSDs as well as CPUs, and memory demand overlaps with GPU-server requirements. Simon expects CPU availability to worsen before improving, while declining to make confident predictions about the broader GPU market. He describes competing for allocations with companies that are also customers and writing software to acquire capacity quickly. Orosz adds a report from Reflection: despite long contracts, it could not obtain more of the CPU and GPU capacity it wanted.

Capacity planning now includes conversations with clouds and large customers about which regions have CPUs and where electrical power will support incoming hardware. Turbopuffer has a useful degree of freedom: a cluster needs CPUs, NVMe SSDs, and object storage. That makes additional clusters relatively straightforward to deploy, although architectural work to accommodate scarcity still consumes engineering time that could go elsewhere.

Supporting many instance types reduces dependence on one allocation pool. Simon names GCP’s C4 machines as a favorite, says C4D performs well after targeted optimization, and also likes the Arm-based C4A family. A SKU is simply a particular machine offering; examples such as i8g illustrate the wider set of options. This flexibility echoes Shopify’s Black Friday/Cyber Monday planning, when teams forecast usage and made cloud commitments months ahead. The cloud feels infinite mainly while your requirements are small.

The financing story begins with an engineering promise. Simon says he guaranteed Cursor roughly $4,000 per month based on the estimated cost of a more efficient implementation than Turbopuffer then had. The software was reliable but simple, and the founders had work to do before their own infrastructure cost matched the price they charged. Their long tenures at Shopify—and Orosz’s at Uber—had also made them attentive to how well simple software ages.

Simon was not yet sure whether this niche search engine could become a venture-scale company. Taking venture capital would create an obligation to deliver a large return on a timeline, extending through a chain of investors that might ultimately include pension funds. His immediate operating model was more concrete: compare Cursor’s bill with the GCP bill, then optimize until infrastructure costs were roughly covered. Additional workloads might eventually pay the founders’ salaries.

He had few financing relationships and describes himself as an outsider twice over: from Aarhus to Ottawa, then from Canada looking toward San Francisco. Before accepting an investment that would redefine the business’s success threshold, he wanted more evidence that he could meet that threshold.

A specific hire changed the calculation. Simon wanted to work with Boyan, whom he knew from IOI and who was nicknamed God for his programming ability. But the founders had gone about six months without salaries and had already spent tens of thousands of dollars on GCP. Simon called Laki, one of his Silicon Valley contacts, with a bounded request: approximately $700,000 to support two engineers for the rest of the year, plus a buffer, while the founders remained unpaid.

His proposal included a stopping condition: if product-market fit and a large opportunity were not evident by year-end, they would shut down and return the remaining money. Some investors heard low ambition. Simon saw candor about what he knew and what he still needed to learn. They raised funding, hired Boyan, became profitable later that year, and continued hiring as their conviction grew.

Simon separates fundraising into six motives:

• Research and development: Pay to learn faster. Turbopuffer’s January raise funded its first engineers, Boyan and Morgan, after the founders had financed development through unpaid work and their own cash.
• Growth: Spend to bring an existing product to a larger market.
• Founder ego: Seek a large number and the attention surrounding it. Simon considers this a dangerous motive because it dilutes existing employees and changes the entry price and potential upside for future employees.
• Employee rewards: Provide liquidity during a long company-building journey. He says Turbopuffer took capital in December so employees could sell some equity without waiting for an IPO or another distant event.
• Strategic partnerships: Bring in a relationship that can materially change the company’s trajectory.
• Mergers and acquisitions: Finance an acquisition or related transaction.

The distinction matters because the same fundraising announcement can conceal very different purposes. In Simon’s account, Turbopuffer’s first raise served R&D; its second served employee liquidity.

The closing question turns from machine allocation to how people work together. Orosz notes that many AI companies favor an office for faster iteration. Remote work felt natural to Simon because Shopify’s infrastructure team had long been distributed: persuading every specialist to move to Ottawa was difficult. Outside established database-company hubs such as San Francisco and perhaps New York, he sees a distributed model as a way to reach the people needed to build the company.

Distributed does not mean never meeting. Turbopuffer brings everyone together twice a year, with Banff and Mexico City among the examples. It also names smaller, informal gatherings campfires. When several colleagues happen to be in one place, they invite others to join. The San Francisco campfire around this conference included customer meetings and dinners, turning an existing trip into time together.

Participation beyond the company offsites is optional. Some employees attend those two gatherings and otherwise stay home with their families; others travel frequently. Both fit the model. Simon recounts one employee seeing colleagues together in a New York meeting room, taking an Uber to the Ottawa airport, and flying down to join them. The point is to make that spontaneity possible without making it everyone’s obligation.

Turbo credits add a small incentive. Giving a conference talk or publishing a blog post can earn a credit redeemable for a business-class upgrade on the next flight. The idea has already prompted jokes about a central bank, interest rates, and a betting market for credits. Volunteering for two days on a conference expo floor can also earn one: it is taxing work, and the reward encourages future time with the team.

Orosz closes by noticing how little of this AI infrastructure conversation required talking about AI itself. Its substance was engineering judgment, curiosity, and the human connections that make difficult work possible. The same company that places durable data in object storage and active data in memory also makes deliberate room for people to meet, help customers, and build trust.