The Engineering Mindset: From PowerPoint to Infrastructure

Simon Eskildsen’s journey began not with formal computer science education, but through a self-taught path of curiosity. Starting with PowerPoint as a tool for logic, he moved through web development and competitive programming (IOI). This early experience taught him a critical lesson: the ability to read technical papers and derive answers independently is more valuable than a traditional degree. At Shopify, he applied this by documenting every unknown term he encountered, creating a personal "crash course" that allowed him to scale from a high school intern to a Principal Engineer managing infrastructure for massive traffic spikes.

The Power of 'Napkin Math'

Eskildsen argues that engineers often rely on flawed benchmarks to make infrastructure decisions. His "napkin math" project—a collection of performance metrics for hardware (DRAM bandwidth, S3 latency, NVMe speeds)—serves as a sanity-check tool. By calculating the theoretical limits of a system, he can identify when a benchmark is misleading. If a search query takes 10 seconds but the math suggests 10 milliseconds, he knows the bottleneck is either in the query plan, the hardware configuration, or the benchmark methodology itself. This approach prioritizes understanding the physical limits of hardware over uncritical reliance on black-box performance tests.

Building Turbopuffer: Rethinking Database Architecture

Turbopuffer was born from the realization that modern vector databases were unnecessarily expensive and complex. By leveraging S3 as the primary storage layer, Eskildsen and his co-founder, Justine, optimized for cost and scale. The core innovation lies in understanding how to batch operations effectively to overcome the limitations of f-sync latency. By treating the database as a system that can be optimized through deep hardware awareness, they achieved a price point of roughly $1 per million vectors—a significant reduction compared to existing market solutions.

Lessons in Scaling and Failure

During his time at Shopify, Eskildsen developed Toxiproxy, a tool designed to simulate network and database failures in CI environments. He realized that most systems fail because they do not handle stateful component outages gracefully. By injecting faults (like closing file descriptors or simulating slow disk I/O) into the test suite, his team uncovered deep-seated issues in Rails and MySQL drivers that were otherwise invisible in production. This philosophy of "testing for failure" remains a cornerstone of his engineering approach, emphasizing that robust systems are built by assuming components will fail, not by hoping they won't.

Key Takeaways

  • Build your own intuition: Don't rely on benchmarks alone. Use "napkin math" to calculate the theoretical performance of your system based on hardware limits.
  • Peel back the layers: When you encounter a technical term or concept you don't understand, document it and research it until you can explain the mechanics at a low level.
  • Test for failure: Use tools like Toxiproxy to simulate infrastructure failures in CI. If your application can't handle a database connection drop, it isn't production-ready.
  • Understand the hardware: Databases are ultimately bound by the physical limits of storage and memory. Knowing the cost and latency of S3 vs. NVMe vs. DRAM is essential for architectural decisions.
  • Founder's perspective: Raising venture capital should be a strategic decision, not an ego-driven one. Be mindful of the dilution impact on your team.

Notable Quotes

  • "I just got obsessed with this question... I just wanted to know keep learning how computers work. And I think that this is something that I now look for when we interview engineers: that you just can't help yourself but trying to peel back the layers."
  • "I hate benchmarks so much because that's not a satisfying answer to me... one of us is wrong: either there's a gap in my understanding, which is very likely, or you benchmarked the wrong thing."
  • "Yeah, you could do a million vectors for a dollar. And before that, I think the cheapest was maybe $100 per million for something that actually worked."
  • "The third reason to raise capital is for the founder's ego... I wish that it was more talked about because you're diluting all of your employees when you do it."