AI Engineer onepage/ Turbopuffer
Gergely Orosz × Simon Eskildsen · 56:30
這支影片在講：把昂貴的向量資料庫，建立在 S3 的成本曲線上
turbopuffer 的共同創辦人 Simon Eskildsen 從 Shopify 的基礎設施經驗出發，拆解為何把資料庫的耐久層放進 S3、如何用批次化處理成本，以及一間 infra 公司該如何面對 GPU 稀缺、定價與融資。
Published: 2026-08-03AI EngineerVideo ID: jQDXzEVHMSE
01 / 問題
向量檢索太貴
早期可用方案的百萬向量成本約為 100 美元；成本過高會直接限制產品能存多少資料、能服務多少使用者。
02 / 反轉
把耐久資料留在 S3
不把每一份資料都綁在昂貴、長駐的資料庫儲存層；利用物件儲存的價格與耐久性，再處理資料庫讀寫的設計難題。
03 / 解法
用系統取捨換成本曲線
批次化能攤薄 fsync 的固定成本。背後的工程不是單點最佳化，而是把延遲、吞吐、複雜度和美元成本一起算。
Signals
四個最值得帶走的數字與轉折
Shopify scale
1K → 1M
Simon 在 Shopify 參與把基礎設施擴展到百萬 RPS 等級的歷程。
Vector cost
$100 → $1
每百萬向量的可用成本，從約 100 美元降到約 1 美元。
Cursor pricing
$4K / mo
為首批大型客戶承諾的月費目標，後來成為正式定價的約束。
Runtime
56:30
一場從競程、Shopify、S3 資料庫到資本策略的完整創業工程訪談。
Core story
從工程生涯到 Turbopuffer 的三段推理
01 / 規模
先在高流量環境學會：系統的瓶頸常常不是直覺所在
從競程與高中加入 Shopify，到面對高速成長的 infra，Simon 的脈絡提醒我們：規模化不是先選「最強」的元件，而是持續把真正的限制因素量化。這也導向後來對 fsync 與批次化的執著。
02 / 儲存
S3 很便宜，但不能假裝它是一個傳統資料庫
影片在 20:40 起說明 Turbopuffer 的起源，24:46 進入在 S3 上做資料庫的設計挑戰。核心取捨是承認物件儲存的特性，並把快取、索引、批次寫入與查詢路徑設計成能承受這些特性。
03 / 商業
成本承諾會反過來塑造技術與定價
Cursor 在 28:41 成為第一個大型客戶；團隊承諾把帳單壓到每月 4,000 美元，最後也以此作為公開定價。這不是單純折扣，而是用可交付的 unit economics 當工程設計的驗收條件。
Decision map
影片給資料與 AI infra 團隊的實務啟發
把成本模型寫進架構決策除了 p99 latency 與 QPS，也要問「每百萬筆資料、每次檢索、每位客戶」的成本。沒有這層，低價承諾很容易在規模上來後崩解。
用 batch 對抗固定寫入成本fsync 的成本不隨 payload 線性變化；合適的批次可以攤薄固定開銷，但必須清楚揭露它對延遲、資料可見性與故障恢復的影響。
讓最早的客戶約束你的產品真相首批客戶不是只有 logo。若能把承諾轉成明確的成本、效能與可靠性指標，它會成為比抽象 roadmap 更有力的優先級機制。
資本不是唯一的擴張解43:06 後談到雲端競爭、CPU 稀缺與融資。資本能買時間與容量，但也稀釋團隊；先辨識要解的是供給、銷售還是創辦人焦慮。
Watch guide
觀看時可特別留意的章節
8:46 — Shopify 的規模化挑戰理解創辦人後來如何把 production 經驗轉化為資料庫設計直覺。
20:40–30:33 — Turbopuffer 的動機與 S3 設計本片最技術密集的段落：為什麼用 S3，以及以成本為主軸的向量資料庫取捨。
35:36–43:06 — GPU、雲端競爭與資源稀缺從 Nvidia 與雲端 infra 的現實，理解基礎設施產品面對的外部限制。
43:06–51:45 — 融資與 remote-first 團隊技術公司如何評估融資動機，以及以「campfire」維持遠距文化的觀點。
Source video