Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO)
Turbopuffer’s early architecture shows a useful agent-era discipline: ship the smallest system that tests demand, then optimize against measured hardware constraints. The transcript offers principles, not benchmarks.
Turbopuffer’s first vector-search design put clustered vectors and centroids in files, fetched nearby clusters from S3, and used an Nginx cache on **one server**. Its founders drew on **eight years at Shopify**, and Cursor later adopted the database after other Postgres-based approaches.
Builders working with agents should keep generated architecture proportional to the current problem: start with inspectable primitives, measure latency and cost, and add bespoke machinery only after demand appears. Hardware flexibility also matters when CPU capacity is constrained.
Turbopuffer’s first vector-search design put clustered vectors and centroids in files, fetched nearby clusters from S3, and used an Nginx cache on **one server**. Its founders drew on **eight years at Shopify**, and Cursor later adopted the database after other Postgres-based approaches. Builders working with agents should keep generated architecture proportional to the current problem: start with inspectable primitives, measure latency and cost, and add bespoke machinery only after demand appears. Hardware flexibility also matters when CPU capacity is constrained. The supplied transcript is incomplete and conversational. It does not provide comparative performance, cost figures, migration details, or enough evidence to generalize Turbopuffer’s architecture to other workloads.
This reinforces an evidence-gated approach to agent infrastructure: begin with simple, inspectable components and introduce specialized architecture only when measured latency, cost, or capacity demands it. Turbopuffer is a useful origin story for that discipline, but the incomplete account cannot validate its design as a general database pattern.