Retrieval After RAG: Hybrid Search, Agents, and Database Design — Simon Hørup Eskildsen of Turbopuffer

Поиск после RAG: гибридный поиск, агенты и проектирование баз данных — Simon Hørup Eskildsen из Turbopuffer

Turbopuffer вырос из приложения для чтения.

В 2022 году Simon помогал друзьям из Readwise масштабировать инфраструктуру для долгожданной функции: рекомендации статей и семантический поиск. Readwise тратил ~$5 тыс./мес. на реляционную базу данных, а векторный поиск обошёлся бы в ~$20 тыс./мес., что делало фичу слишком дорогой для запуска. В 2023 году, обдумав проблему Readwise, Simon решил «построить поисковый движок» — так появился Turbopuffer.

Мы обсуждаем:• Путь Simon: Дания → инфраструктура Shopify почти десять лет → «ангельская инженерия» в стартапах вроде Readwise, Replicate и Causal → Turbopuffer, почти случайно ставший компанией • История с Readwise: создание раннего рекомендательного движка сразу после момента ChatGPT, осознание его работоспособности, а затем понимание, что это будет стоить ~$30 тыс./мес. для компании, тратящей ~$5 тыс./мес. на всю инфраструктуру, и одержимость исправлением этой структуры затрат • Почему Turbopuffer — это «поисковый движок для неструктурированных данных»: убеждение Simon в том, что модели могут научиться рассуждать, но не способны сжать все знания мира в несколько терабайт весов, поэтому им нужна связь с системами, хранящими истину в полном объёме • Три ингредиента для создания великой компании баз данных: новый тип нагрузки, новая архитектура хранения и способность со временем поддерживать любой план запросов, который понадобится клиентам • Архитектурная ставка Turbopuffer: полная опора на объектное хранилище и NVMe, отказ от традиционного слоя консенсуса и построение на облачных примитивах, ставших возможными лишь в последние годы

• Почему Simon ненавидел эксплуатацию Elasticsearch в Shopify: годы мучительных дежурств сформировали его одержимость простотой, производительностью и устранением разброса состояния по нескольким системам • История с Cursor: запуск Turbopuffer как скромного побочного проекта, письмо от Cursor на следующий день, перелёт после звонка в 4 утра и помощь Cursor в снижении затрат на 95% с исправлением экономики в расчёте на пользователя

• История с Notion: покупка тёмного оптоволокна, настройка TCP-окон и поглощение межоблачных затрат, потому что Simon отказался идти на компромисс в архитектуре ради ускорения закрытия сделки

• Почему ИИ меняет уравнение «строить vs. покупать»: дело не столько в том, может ли компания построить поисковую инфраструктуру сама, сколько в том, есть ли у неё на это время — особенно если внешняя команда может ощущаться как продолжение собственной • Почему RAG не умер: компании-разработчики по-прежнему сильно зависят от поиска, и Simon видит, что гибридный поиск — семантический, текстовый, regex, SQL-подобные паттерны — становится важнее, а не менее важным • Как агентные нагрузки меняют поиск: старый паттерн — один вызов поиска в начале; новый паттерн — один агент запускает множество параллельных запросов одновременно, превращая поиск в высококонкурентный вызов инструмента • Почему Turbopuffer снижает цены на запросы: агентные системы кардинально увеличивают объём запросов, и Simon ожидает, что инфраструктура поиска адаптируется к огромным всплескам конкурентного поиска, а не к малому числу тщательно подобранных вызовов • Философия «игры с открытыми картами»: привычка Simon быть радикально честным с инвесторами, включая слова Lachy Groom о том, что он вернёт деньги, если Turbopuffer не найдёт PMF к концу года • «P99-инженер»: фреймворк Simon для построения компании с высокой плотностью талантов — отклонять по умолчанию, если кто-то в команде не чувствует достаточно сильно, чтобы бороться за кандидата

—Simon Hørup Eskildsen• LinkedIn: https://www.linkedin.com/in/sirupsen• X: https://x.com/Sirupsen• https://sirupsen.com/aboutTurbopuffer• https://turbopuffer.com/

Полное видео подкаста

Таймкоды

00:00:00 Обещание PMF для Lachy Groom00:00:25 Вступление и биография Simon00:02:19 Что такое Turbopuffer на самом деле00:06:26 Shopify, Elasticsearch и боль, стоящая за компанией00:10:07 Эксперимент с Readwise, давший начало Turbopuffer00:12:00 Инсайт, который не отпускал Simon00:17:00 Консистентность S3, NVMe и архитектурная ставка00:20:12 История с Notion: задержка, тёмное оптоволокно и убеждённость00:25:03 «Строить vs. покупать» в эпоху ИИ00:26:00 История с Cursor: от раннего запуска до прорывного клиента00:29:00 Почему поиск по коду всё ещё важен00:32:00 Поиск в эпоху агентов00:34:22 Ценообразование Turbopuffer в эру ИИ00:38:17 Почему Simon выбрал Lachy Groom00:41:28 Стать основателем осознанно00:44:00 Философия «P99-инженера»00:49:30 Подчинить софт своей воле00:51:13 Будущее Turbopuffer00:57:05 Увлечение Simon чаем00:59:03 Чайные наборы, X Live и P99 Live

Транскрипт

Simon Hørup Eskildsen: Думаю, я не говорил этого публично раньше, но я просто позвонил Lachy и сказал — слушай, Lachy, если к концу года у нас не будет PMF, мы просто вернём тебе все деньги. Просто мы с Justine не хотим работать над этим, если оно по-настоящему не работает.

Так что мы хотим дать этому лучший шанс в этом году, и мы реально пойдём ва-банк. Мы наймём кучу людей. Мы просто будем честны со всеми. Когда я не знаю, как играть в игру, я просто играю с открытыми картами. Lachy оказался единственным человеком, которого это не напугало. Он сказал: я никогда не слышал, чтобы кто-то такое говорил.

Alessio: Привет всем, добро пожаловать в подкаст Latent Space. Это Alessio Fanelli, партнёр Decibel, и со мной swyx, редактор Latent Space.

swyx: Привет-привет, мы всё ещё записываем в студии Kernel впервые. Очень рады. И сегодня у нас в гостях Simon Eskildsen из Turbopuffer. Добро пожаловать.

Simon Hørup Eskildsen: Большое спасибо, что пригласили.

swyx: Turbopuffer просто невероятно набрал обороты, и я должен отметить, что вы — ещё один участник датской мафии Орхуса, откуда вышло множество легендарных программистов, таких как Бьярне Страуструп, Расмус Лердорф, Lars Bak и команда V8, а также команда Google Maps.

Сейчас вы в основном канадец, но разве не интересно? Такое сильное датское присутствие.

Simon Hørup Eskildsen: Да, я не так давно писал пост о влияниях. Я вырос в Дании. Уехал, когда мне было 18, в Канаду работать в Shopify. И я бы всё равно сказал, что ощущаю себя больше датчанином, чем канадцем.

Ещё этот странный акцент — я не могу произнести «th», потому что... ну, не знаю. Моя жена тоже канадка. И я думаю, одна из вещей в Дании — там просто такой безжалостный прагматизм, и ещё большое внимание к эстетике. Людям реально важно, как вещи выглядят.

У Канады много достоинств, у США тоже, но из Дании можно многое перенять. Хотя я не знаю, что такого в воде в Орхусе. И не уверен, что меня можно считать частью мафии — по сравнению с выдающимися людьми, которых мы только что назвали.

Rasmus Lerdorf тоже датско-канадский. Да. Не знаю, где он сейчас живёт, но он создатель PHP.

swyx: Да. И, конечно, Toby Lütke — немец, но тоже переехал в Канаду. Это интересный ход — такой импорт талантов.

Alessio: Я бы хотел услышать от вас определение Turbopuffer, потому что вас можно назвать векторной БД — хотя это, возможно, плохое слово в некоторых кругах — а можно поисковым движком.

Давайте просто начнём с этого, а потом, может, пройдёмся по истории того, как вы к этому пришли.

Simon Hørup Eskildsen: Конечно. Turbopuffer на данный момент — это поисковый движок. Мы делаем полнотекстовый поиск и векторный поиск, и именно на этом мы специализируемся. Если вам нужно что-то значительно большее — возможно, это пока не то место. Но Turbopuffer — это целиком про поиск.

Ещё я думаю об этом так: мы можем взять все знания мира, все эксабайты данных, и использовать эти токены для обучения модели, но мы не можем сжать всё это в несколько терабайт весов. В несколько терабайт весов можно сжать умение рассуждать о мире, умение осмысливать знания.

Но нужно как-то подключить модель к чему-то внешнему, что хранит информацию в полном объёме и достоверности. Именно этим мы и намерены стать. Это звучит немного высокопарно, но быть поисковым движком для неструктурированных данных — вот на чём сейчас сфокусирован Turbopuffer.

Alessio: Давайте разберёмся. Кто-то скажет: а разве Elasticsearch этого не делает? А кто-то спросит: это поиск по моим данным — ближе к RAG или к публичному поиску типа Google? Как вы разграничиваете разные типы поиска?

Simon Hørup Eskildsen: Я обычно думаю об этом так: есть много компаний баз данных, и если хочешь построить по-настоящему большую компанию БД, нужно, чтобы в воздухе витало несколько ингредиентов.

А это случается примерно раз в 15 лет. Нужна новая нагрузка. По сути, нужна амбиция, чтобы каждая компания на Земле имела данные в вашей базе. Причём неоднократно. Посмотрите на Oracle: думаю, вы не найдёте компанию с цифровым присутствием, у которой так или иначе нет данных в базе Oracle.

И я думаю, что сейчас это верно и для Snowflake, и для Databricks. 15 лет спустя — или даже больше — нет компании на Земле, которая прямо или косвенно не использует Snowflake, Databricks или какую-то из крупных аналитических баз. И я думаю, мы сейчас в таком же моменте.

Я не думаю, что в ближайшие годы найдётся компания, которая прямо или косвенно не сделает все свои данные доступными для поиска и не подключит их к ИИ. Так что нужна эта новая нагрузка — нужно, чтобы что-то происходило, порождающее новый тип нагрузки. И эта нагрузка — подключение очень больших объёмов данных к ИИ.

Второе условие для создания большой компании БД — нужно какое-то новое фундаментальное изменение в архитектуре хранения, невозможное для баз данных предыдущего поколения. Посмотрите на Snowflake и Databricks: массовый флот HDD, ставший товаром, — это просто не существовало раньше.

Этого не было в воздухе в девяностых. Не было S3 и подобных сервисов. И я думаю, архитектура, ставшая возможной сейчас, но невозможная 15 лет назад, — это полная ставка на NVMe SSD. Она требует особого типа архитектуры базы данных, который сложно приделать к уже существующим базам, включая те, которые вы упомянули. Второе — полная ставка на объектное хранилище, куда большая, чем была возможна 15 лет назад. У нас нет слоя консенсуса, у нас нет практически ничего. Можно выключить все серверы Turbopuffer, и мы не потеряем ни одного байта данных, потому что мы полностью положились на объектное хранилище.

И это означает, что наша архитектура невероятно проста. Итак, второе условие: первое — новая нагрузка, означающая, что каждая компания на Земле прямо или косвенно использует вашу базу. Второе — новая архитектура хранения, из-за которой предшественники не могут делать то, что делаете вы.

Третье, что нужно для создания большой компании БД, — со временем реализовать практически каждый план запросов к данным. Это значит, что нельзя застрять на одной функции базы данных. Она должна постоянно эволюционировать, потому что когда у кого-то данные в базе, со временем он ожидает возможности задать ей практически любой вопрос.

Поэтому нужно довести архитектуру хранения до предела её возможностей. Вот три условия.

swyx: Я хотел бы немного поговорить о мотивации. Вы ушли из Shopify, были ведущим инженером по инфраструктуре. А ещё руководили Kernel Labs внутри Shopify.

И потом консультировали Readwise, и это дало вам идею. Хочу, чтобы вы рассказали эту историю. Может, вы её уже рассказывали, но просто познакомьте людей с новой нагрузкой и моментом озарения для Turbopuffer.

Simon Hørup Eskildsen: Конечно. Да, я провёл почти десять лет в Shopify.

Я был в команде инфраструктуры с довольно ранних дней, примерно с 2013 года. Тогда казалось, что всё растёт невероятно быстро — все метрики удваивались год от года. По сравнению с тем, с чем сталкиваются компании сегодня, это выглядит мило — некоторые видят такой рост помесячно.

Конечно, Shopify стабильно растёт уже очень долго. Но я провёл десять лет, занимаясь одним: убедиться, что сайт работает сегодня и будет работать через год. По большей части это было связано с тем, что Кардашьяны генерировали огромный трафик на Shopify, постоянно обновляя мерч и развивая свои бизнесы.

Нам нужно было просто справляться с этим. Иногда это были события с миллионом запросов в секунду. У нас были свои дата-центры, мы переезжали в облако, шардировали всё подряд. Десять лет я масштабировал базы данных, потому что это фундаментально самое сложное, что нужно масштабировать в таких системах.

База данных, с которой мне было сложнее всего справляться и от дежурств по которой я больше всего страдал, была Elasticsearch. С ней было крайне трудно работать. И я видел множество проектов, чьи амбиции сдерживались именно ею.

swyx: Причём самохостинг.

Самохостинг, потому что...

Simon Hørup Eskildsen: Да, и это было как коммерческое решение — речь о 2015 годе, конкретная эпоха. Сейчас, вероятно, со многим стало лучше. Но тогда это было мучительно, и я всё думал: это же инвертированный индекс, он должен хорошо работать с такими запросами.

Но часто мы не могли заставить его делать именно то, что нам нужно, — по сути, дать нам прямой доступ к Lucene. Так что это просто работало фоном, и мы судорожно масштабировали, когда приходилось. Потом я ушёл, и когда уходил, не был уверен, чем хочу заниматься.

Я ведь провёл почти десять лет в одной компании. Я там вырос. Начал работать в 18 лет.

swyx: Вы работали только с Rails?

Simon Hørup Eskildsen: Ну да, Rails. Он поклонник Rails. Обожаю Rails. Просто отлично.

Alessio: Мы все мечтаем, чтобы можно было по-прежнему работать на Rails.

swyx: Знаю, знаю, но я пытался выучить Ruby — слишком много способов сделать одно и то же. Это моя претензия. Я знаю, что есть правильный способ.

Просто вариантов слишком много.

Simon Hørup Eskildsen: Мне нравится. Не уверен, что стал бы использовать его сейчас — с Claude Code и Cursor и всем остальным. Но если я просто сажусь писать код сам — я мыслю именно так.

В общем, я ушёл и не был уверен. Поговорил с парой компаний и понял: мне нужно увидеть побольше, прежде чем решить, на чём сосредоточиться. Я назвал это «ангельская инженерия» — прыгал между компаниями друзей по три месяца, помогал с чем-то.

Получал немного акций и решал интересные инфраструктурные задачи. Работал с кучей компаний: Readwise, Replicate, Causal — знаете, это табличный движок, где можно работать с распределениями.

Их недавно купили. Мы использовали их для FP&A в Turbopuffer. Куча таких компаний — было супер весело. И когда случился момент ChatGPT, я был с Readwise. Мы готовились к запуску Reader — приложения, где ты складываешь статьи и читаешь потом.

Я как раз приводил их Postgres в порядок — что по сути сводилось к настройке autovacuum. И тут произошёл этот момент, и мы подумали: может, стоит построить маленький рекомендательный движок и попробовать подключить LLM. Модели были ещё не очень хороши, но было ясно, что что-то есть.

И я построил небольшой рекомендательный движок: берём статьи, которые ты недавно читал, эмбеддим все статьи и делаем рекомендации. Он оказался достаточно хорош — когда я прогнал его на данных одного из сооснователей Readwise, я обнаружил статьи о рождении ребёнка.

Я такой: о боже, я не знал, что у них будет ребёнок. Не знал, что делать с этой информацией, но рекомендательный движок был достаточно хорош, чтобы подсказывать такие статьи. Рекомендации реально работали.

Но Readwise тратил примерно пять тысяч долларов в месяц на всю инфраструктуру. Когда я прикинул на салфетке стоимость эмбеддинга всех статей, размещения их в векторном индексе и вывода в продакшн — выходило около 30 тысяч в месяц. Это было нереально.

Readwise — гордо бутстрапленная компания, и платить 30 тысяч за инфраструктуру одной функции при пяти тысячах за всё остальное было просто невозможно. Так что это попало в категорию «полезно, неплохо работает, но вернёмся, когда подешевеет».

swyx: А масштабируется это по фичам? То есть от пяти до тридцати — это из-за количества... Какой коэффициент масштабирования?

Масштабируется по количеству статей, которые ты эмбеддишь.

Simon Hørup Eskildsen: Да, но я имел в виду, что пять тысяч — это за всё остальное: Heroku, dynos, Postgres, вся остальная инфраструктура. А тридцать тысяч — за одну функцию. Одну: какие статьи связаны с этой.

Это было слишком много. Их бюджет был бы, может, пару тысяч, и это уже казалось бы дорого. Так что мы отложили. Мол, ладно, сделаем позже, подождём, пока подешевеет. И это меня преследовало. Я не мог перестать об этом думать.

Я понимал: здесь явно скрытый спрос. Если бы стоимость была в десять раз меньше, мы бы это выпустили. Это была единственная точка данных, которая у меня была. Я не ходил и не опрашивал других. Просто начал читать — не мог удержаться.

Я не знал, что такое векторный индекс. Едва понимал, как генерируются векторы. Был ранний 2023 — много хайпа вокруг векторных баз данных, они поднимали кучу денег. Я реально ничего об этом не знал. Пробовал маленькие модели, файнтюнил — пытался разобраться.

И я просто сел. У меня есть репозиторий на GitHub под названием Napkin Math. Там строки вроде: вот столько пропускной способности к DRAM, вот столько записей в секунду на SSD, вот сколько пропускной способности на одно подключение к S3.

Все эти числа. И я просто сел и подумал: почему никто не построил базу данных, где всё кладётся в объектное хранилище, а потом «надувается» в NVMe при использовании и в DRAM при активном запросе? Это выглядит довольно очевидным. Единственный минус — при полной ставке на объектное хранилище каждая запись занимает пару сотен миллисекунд. Но дальше — сплошные плюсы.

Первый запрос — полсекунды. И мне пришло в голову: архитектура отлично подходит. Отлично для объектного хранилища, отлично для NVMe SSD. Просто десять лет назад это было невозможно. Возвращаясь к тому, о чём мы говорили: нужно строить базу данных с минимальным количеством обращений.

Именно так работают современные CPU, NVMe SSD и S3: нужно держать огромное количество незавершённых запросов. Идёшь в S3 — тысяча запросов за один раунд. Ждёшь ответа. Принимаешь новое решение. Повторяешь. И стараешься уложиться максимум в три таких цикла.

Но ни одна база данных не была спроектирована так для NVMe SSD. На NVMe можно достичь пропускной способности, кратной DRAM, если использовать их правильно. То же с S3: можно полностью загрузить сетевую карту, которая обычно не загружена, и получить очень высокую пропускную способность.

Но никто так базу данных не строил. И я подумал: а нельзя ли просто взять все векторы, поместить их в условную систему координат, получить кластеры, положить файл clusters.json на S3, а потом отдельный файл для каждого кластера — cluster1.json, cluster2.json? Это два раунда обращений.

Получаешь кластеры, находишь ближайшие, скачиваешь файлы ближайших кластеров. Два раунда.

swyx: И ближайших соседей считаете локально.

Simon Hørup Eskildsen: Да-да. И из этого строишь файл. Ультра-простая схема, но первая версия Turbopuffer была не так далека от этого.

Почему этого никто не сделал раньше?

Alessio: В тот момент, с точки зрения нагрузки, вы думали, что это будет чтение-ориентированная штука — для рекомендаций? Типа: запись дорогая, но с ИИ записей на самом деле не так много?

Simon Hørup Eskildsen: На тот момент я особо не задумывался... Хотя нет, мне всегда было ясно, что записей будет много, потому что в Shopify поисковые кластеры делали, не знаю, десятки или сотни запросов на чтение в секунду — человек сидит и вводит текст. А обновлений в секунду были миллионы.

Так что я всегда знал, что соотношение чтения к записи — примерно 1 к 10 или 1 к 100. В случае Readwise чтений тоже было бы куда меньше, чем записей — просто огромный поток данных по сравнению с количеством запросов. Но я не особо думал об этом. В основном думал: какой фундаментально самый дешёвый способ построить базу данных в облаке с доступными примитивами?

И вот он. Одна машина, скажем, терабайт данных в S3, $200 в месяц. Может, 5–10% этих данных нужно держать на NVMe SSD, и ещё меньше — в оперативной памяти. Получается очень дёшево «раздувать» данные.

swyx: Кстати, когда вы говорите, что никто этого не делал — вы бы отнесли Neon к похожему пути? В смысле S3-first и разделение вычислений и хранения.

Simon Hørup Eskildsen: Да, я имел в виду — построить полностью новую базу данных. Не знаю, были ли мы первыми — я просто посмотрел на «математику на салфетке» и подумал: это кажется очевидным.

Уверен, человек сто пришли к этому одновременно — как лампочка и любое изобретение. Это просто витало в воздухе. Думаю, Neon был раньше, но они надстроены поверх Postgres. Они построили архитектуру, где данные в памяти, а потом как бы mmap-ятся обратно в S3. Для OLTP на тот момент это было очень новаторски, но я не видел базу данных, полностью построенную с нуля для этого — без ретрофита. Без слоя консенсуса. С compare-and-swap на объектном хранилище для консенсуса. Не видел, чтобы кто-то зашёл настолько далеко.

Наверняка кто-то был до нас. Не знаю. Я просто смотрел на «математику на салфетке».

swyx: А когда вы говорите «слой консенсуса» — вы сильно полагаетесь на строгую консистентность S3? Да? Ок.

Так что...

Simon Hørup Eskildsen: Это и есть наш слой консистентности. И вот что большинство людей не осознаёт: S3 стал консистентным только в декабре 2020 года.

swyx: Помню, как это вышло во время ковида — люди такие: «о, прикольно». Просто бесплатное обновление.

Они просто объявили: у нас строгая консистентность, ребят. И все такие: ок, круто.

Simon Hørup Eskildsen: Уверен, у них это уже работало в продакшне какое-то время, и они просто сказали: готово.

А люди такие: ок, классно. Но это большой момент. NVMe SSD тоже не были в облаке до примерно 2017 года. Сначала — 2017, NVMe SSD, все такие: «ок, есть один SKU, который это делает, ну и ладно». Проходит пару лет. Потом — S3 становится консистентным в 2020.

И теперь не нужен огромный Foundation DB или ZooKeeper, сидящий и конкурирующий за ключи. Именно так Snowflake и другие обходились...

swyx: Ушло.

Simon Hørup Eskildsen: Именно. Просто исчезло. Отдаёшь на откуп сотням людей, работающих над S3. А compare-and-swap в S3 на тот момент ещё не было.

swyx: Кстати, я не знаю, что это такое, может, объясните.

Да, конечно.

Simon Hørup Eskildsen: Да, итак, compare-and-swap — это, по сути, вот что. Представьте: у вас база данных, и было бы удобно иметь файл metadata.json. В metadata.json — вещи вроде: какие ключи где находятся, что значит какой файл, куча метаданных для работы базы.

Самый простой способ это сделать. Но у вас может быть много серверов, которые хотят менять метаданные — они записали файл и хотят, чтобы метаданные его отразили. Скажем, сто нод конкурируют за этот metadata.json. Compare-and-swap позволяет скачать файл, внести изменения и записать его обратно только если он не изменился за это время.

Если изменился — повторяете. Просто циклы повторов. Если сто нод это делают, будет медленно, но со временем сойдётся. Этого примитива не было в S3. Не было до конца 2024 года. Зато он был в GCP.

Настоящая история совсем не в том, что я сел и всё спланировал. Я подумал: ладно, начнём на GCS, S3 получит это позже. Вовсе не так — мы начали, нам просто повезло. Мы начали на GCP, потому что Shopify работал на GCP, и это была платформа, которую я знал лучше всего.

Я знал канадскую команду оттуда, потому что работал с ними в Shopify. Так что естественно было начать там. И когда мы начали строить базу данных, думали: да, нам нужен слой консенсуса — ZooKeeper или что-то такое.

Но потом обнаружили compare-and-swap: о, можно отложить проблему! Просто metadata.json, и нормально. Наверное, нормально. И мы продолжали откладывать, пока не получили очень сильную уверенность в идее. А потом фактически поставили компанию на то, что S3, скорее всего, тоже это получит. Стало реально тяжело примерно в середине 2024.

Потому что мы закрывали сделку с Notion, а они работали в AWS. И мы такие: поверьте, вам правда лучше, чтобы мы запустили это в GCP. А они: не уверены. У нас всё в AWS. Задержка между облаками была огромной, и мы были настолько уверены в своей архитектуре, что купили тёмное оптоволокно между регионами AWS и GCP в Орегоне, через точку обмена. GCP такие: мы никогда не видели, чтобы стартап... что тут происходит?

А мы просто: нет, мы не хотим делать метаданные на S3. Мы настраивали TCP-окна, всё что можно, чтобы снизить задержку — настолько сильна была уверенность. Итого три условия: compare-and-swap для метаданных — не было в S3 до конца 2024. Консистентность S3 — появилась в декабре 2020. И NVMe SSD — появились в облаке в 2017.

swyx: В каком-то смысле это огромная история успеха облачных технологий — что вы смогли всё это собрать. Но ещё и покупка тёмного оптоволокна — такого я вообще никогда не слышал.

Simon Hørup Eskildsen: Для крупной компании это нормально — подключаешь свой дата-центр и всё. Но наш случай был уникально болезненным с Notion, потому что в Ashburn, Вирджиния, дата-центры GCP и AWS находятся в пределах миллисекунды друг от друга на публичных точках обмена.

А в Орегоне дата-центр GCP сидит в паре сотен километров к востоку от Портленда, а регион AWS — в самом Портленде, и сетевой обмен идёт через Сиэтл. Это полные 14 миллисекунд. Так что нам пришлось пойти через точку обмена в Портленде.

И...

swyx: И вы предпочли это, а не поднять ZooKeeper и...

Simon Hørup Eskildsen: Однозначно. Это не имеет состояния — я не хочу состояние в двух системах. И я думаю, это всё продиктовано тем, что Justine, мой сооснователь, и я провели столько лет на дежурствах. Худшие аварии — когда состояние в нескольких местах рассинхронизируется.

Так что это шло из очень чистого источника боли — мы представляли, из-за чего нас могут разбудить в 3 часа ночи. И ZooKeeper в этом списке не значился.

swyx: Когда вы разговариваете с Notion или кем-то — им важно это или они просто...

Simon Hørup Eskildsen: Им важна задержка.

swyx: Задержка, стоимость. Всё.

Simon Hørup Eskildsen: Им важна только задержка. И мы просто взяли затраты на себя. Мы сказали: у нас сильная уверенность. В какой-то момент переведём их на AWS. Так что просто купим оптоволокно, не важно. Обычно при покупке оптоволокна берут несколько линий.

А мы такие: можем позволить только одну, но протестируем — при переходе на публичный интернет всё работает гладко. Так что мы сделали кучу всего... В общем, да, это было круто.

Alessio: Представляю разговор с представителем GCP: нет, мы купим оптоволокно, потому что знаем, что через полгода уйдём от вас на AWS.

Но пока — вот так. Это...

Simon Hørup Eskildsen: Ну, на самом деле эта нагрузка до сих пор работает на GCP. Потому что всё было настолько надёжно. Дело было не в уходе с GCP, а в честности — мы просто хотели дать Notion ту задержку, которую они заслуживали.

Мы не хотели, чтобы им приходилось думать обо всём этом. Они ещё сказали: исходящий трафик будет дорогим. А мы: ладно, чёрт с ним, сделаем VPC-пиринг с вами в AWS, возьмём затраты на себя. Что нужно — то и сделаем.

Alessio: А какие конкретно были нагрузки? Потому что когда думаешь об ИИ, 14 миллисекунд — это вроде бы ничего в масштабах генерации модели.

Simon Hørup Eskildsen: Нам сказали, какую задержку нужно побить. Мы смотрели на трейсы и прикидывали: какие ещё ответвления трейса возможны?

Потому что если у вас 14 вместо 7 миллисекунд, можно вместить ещё один раунд. Пришлось настраивать TCP, чтобы отправлять как можно больше данных за каждый раунд, прогревать все соединения. Много вещей накапливается из-за таких задержек. Но в целом — нам просто нужно было побить задержку конкурентного решения.

swyx: То есть Notion — они же сами компания баз данных. Они могли бы сделать это сами, у них много инженерии баз данных. Как вы вообще зашли в дверь?

Simon Hørup Eskildsen: В последний раз в Сан-Франциско я разговаривал с одним из инженеров, который был нашим чемпионом в Notion.

Они просто пытались убедиться, что стоимость на пользователя соответствует нужной экономике. Я думаю об этом так: мне нужно заработать маржу на том, что облако берёт с меня, а мои клиенты должны заработать маржу на том, что я беру с них. Просто — маржа по всей цепочке, и так строится продукт.

Наши клиенты должны принимать правильный для себя набор компромиссов Turbopuffer, и если им это подходит — отлично.

swyx: Вы чувствуете, что конкурируете со внутренней разработкой или с другими вендорами?

Simon Hørup Eskildsen: Да, простите, это всё было подводкой к вашему вопросу. Один из инженеров Notion рассказал мне, что они сидели и, наверное, на салфетке нарисовали: почему никто такого не построил? А потом увидели Turbopuffer — и это было буквально оно. И я думаю, ИИ изменил уравнение «строить vs. покупать»: дело не в том, могут ли они это построить, а в том, есть ли у них время.

Они почувствовали: если это команда, которая может это сделать, и они ощущаются как продолжение нашей команды — мы можем двигаться гораздо быстрее. Это было бы очень полезно. И они нас реально проверили — у нас были очень длинные ночи, чтобы сделать этот POC.

Notion стали нашим вторым крупным клиентом после Cursor, с которым тоже было много бессонных ночей.

swyx: Может, перейдём к истории с Cursor? Они очень вас хвалят за то, как тесно вы работали. Я слышал эту историю от Sualeh, но любопытно, как она выглядит с вашей стороны.

Simon Hørup Eskildsen: Я, кстати, не слышал версию Sualeh, так что можете потом сопоставить. Как я помню — на следующий день после запуска... Всё лето я работал над первой версией. Justine ещё не участвовала, потому что я никому не говорил тем летом, над чем работаю.

Я просто залочился на разработке, потому что иначе легко спутать разговоры о чём-то с реальным делом. Так что я просто делал. Запустил — и в тот момент Turbopuffer был бинарником на Rust, работающим на одной восьмиядерной машине в T-инстансе.

Деплой выглядел так: смотрю на лог запросов, если запросов нет — Ctrl+C и обновляю бинарник. Буквально. Максимально минималистично. Намеренно — в Shopify мы всё время так делали. Запускали вещи в tmux перед тем, как что-то обретало хотя бы намёк на PMF.

И тут один из сооснователей Cursor — Arvid — написал. Команда Cursor — они все как контендеры IOI. Общаются буллет-поинтами и фактами. Потрясающая переписка: вот наш QPS, вот сколько платим, вот куда идём. Мы просто переписывались буллет-поинтами. Я пытался созвониться несколько раз, но они были на пике поиска PMF — конец 2023.

И однажды Sualeh пишет мне в пять... Нет, в 4 утра по Тихоокеанскому: «Ты можешь сейчас созвониться?» Я на Восточном побережье, было 7 утра. Ответил: да, конечно. Начали говорить, и что-то... Тогда я ничего не знал о продажах.

Но что-то подтолкнуло меня: я должен поехать к этой команде. Что-то здесь есть. Полетел в Сан-Франциско, пришёл к ним в офис, и как я помню — когда я пришёл, у них лежал Postgres. Sualeh вам это рассказывал? Нет. Ок. Postgres лежал, и они были этим заняты.

Я пытался как-то помочь. Знал немного о базах данных — вернувшись к настройке autovacuum, я такой: «Думаю, вам нужно настроить autovacuum.» Потом вечером обсуждали: как бы выглядело сотрудничество с нами?

И я просто сказал: мы — всё, полностью. Сделаем всё, что скажете. Они мигрировали всё за неделю-две, и мы снизили их затраты на 95% — думаю, это в целом починило их экономику в расчёте на пользователя. И решило кучу других проблем. Мы были... Justine — вот тогда я попросил её стать сооснователем, она была лучшим инженером, с которым я работал в Shopify.

Она жила в двух кварталах, и мы просто: ладно, давай сделаем. И сделали. Помогли им мигрировать и следующие месяц-два просто пахали, чтобы ни разу не стать проблемой. Вот такая история с Cursor.

swyx: А код — это другой тип нагрузки, чем обычный текст? Это просто текст — то же самое?

Что-то отличается?

Simon Hørup Eskildsen: Нагрузка Cursor — они эмбеддят всю кодовую базу. Разбивают на чанки, как считают нужным. У них своя модель эмбеддинга, об этом они рассказывали публично. И по их eval'ам...

Есть один eval, где получается 25% улучшение на конкретной нагрузке. У них куча постов об этом. Лучше всего работает на больших кодовых базах. Они обучили собственную модель эмбеддинга. Если вы используете агент Cursor — он делает поиски.

Они также публично рассказывали, что пост-обучили модель для хорошего семантического поиска. Так что отлично находит код, похожий на данный, или код, который делает что-то конкретное. Для таких запросов они дополнительно используют grep.

swyx: Да.

Simon Hørup Eskildsen: Конечно.

swyx: Большая тема для обсуждения — мол, RAG мёртв, потому что grep, ну знаете...

Simon Hørup Eskildsen: Я просто вижу огромный спрос от компаний-разработчиков на поиск.

swyx: Поиск повсюду. Да.

Simon Hørup Eskildsen: Мы видим спрос. И я предпочитаю кейс-стади, а не размышлять, куда всё идёт, как макроэкономист от ИИ — это оказалось гигантской тратой времени, потому что никто не может предсказать ничего из этого.

Так что я просто коллекционирую кейс-стади. Cursor отлично рассказывает о том, что делает, и надеюсь, другие лаборатории кодинга, использующие Turbopuffer, сделают то же. Но поиск действительно даёт разницу на определённых запросах. Мы также умеем текстовый поиск и regex. Но ещё хочу сказать: система безопасности Cursor в работе с Turbopuffer исключительна. У них своя модель эмбеддинга, которую очень сложно реверс-инжинирить. Они обфусцируют пути к файлам.

По данным в Turbopuffer очень сложно что-то узнать о кодовой базе. Плюс для своих клиентов они шифруют данные собственными ключами в бакете Turbopuffer. Это реально очень хорошо спроектировано.

swyx: Это дополнительные меры, которые они предприняли для работы с вами, потому что вы — не часть Cursor.

Именно. Это просто лучшая практика при работе с любой базой данных, не только с вами. Понятно. Для меня вывод такой: все нагрузки — гибридные. Хочется и семантику, и текст, и regex, и SQL.

Не знаю... Но глупо делать ставку только на один тип запросов.

Simon Hørup Eskildsen: Мне очень нравится, как Sualeh из Cursor об этом говорит. Я сейчас, наверное, переврю, и знаете — я специалист по масштабированию баз данных, не по обучению моделей. Знаю только то, что говорит интернет и то, что...

Он описывает это как кэширование вычислений. У вас есть точка во времени, где вы смотрите на определённый контекст, сфокусированы на определённом фрагменте, и говорите: это слой нейросети в этот момент. Кажется, фундаментально полезно кэшировать вычисления таким образом.

Как будет меняться ценность этого со временем — не знаю, но похоже, что ценность большая.

Alessio: Расскажите немного об эволюции нагрузки. Ещё два года назад поиск — это был один запрос в начале обработки LLM, чтобы собрать контекст. Теперь есть агентный поиск — как хотите назовите, — где модель одновременно пишет и меняет код, и потом снова ищет.

Какие новые типы нагрузок или изменения в архитектуре вам пришлось сделать?

Simon Hørup Eskildsen: Вы правы. Когда я думаю о RAG, я представляю: вот окно контекста в 8 000 токенов, и нужно использовать его по максимуму. Поиск был способом это сделать. Теперь всё движется к тому, чтобы просто дать агенту делать своё дело.

Возвращаясь к тому, о чём говорили: LLM отлично рассуждает с данными, а мы — просто вызов инструмента. И всё чаще мы видим, что наши клиенты именно так нас используют. Сейчас от клиентов растёт спрос на высокий параллелизм. Notion делает невероятное количество запросов за каждый раунд. И когда я пользуюсь агентом Cursor, тоже вижу больше параллелизма, чем когда-либо.

Похоже на то, как мы проектировали базу для максимального параллелизма в каждом раунде — агенты делают то же самое. Это новое. Означает огромное количество запросов одновременно к набору данных, пока он тёплый, за минимальное число раундов.

swyx: Можно уточнить?

Simon Hørup Eskildsen: Да.

swyx: Это батчинг нескольких пользователей или один пользователь генерирует множество...

Simon Hørup Eskildsen: Один пользователь, один агент генерирует множество запросов.

swyx: Параллельный поиск по куче вещей.

Simon Hørup Eskildsen: Именно.

swyx: Да-да. Клиника тоже так делала для быстрого контекста — восемь параллельных запросов.

Simon Hørup Eskildsen: Да.

swyx: И интересная проблема: как обеспечить достаточное разнообразие, чтобы не делать один и тот же запрос восемь раз?

Simon Hørup Eskildsen: Думаю, гибридность здесь тоже помогает — это совершенно другой способ поиска, ещё одна ось разнообразия.

Это большое изменение. Раньше был один вызов, потом LLM несколько секунд генерирует ответ. Теперь мы видим огромное количество запросов. Мы снизили цены на запросы. Наверное, я впервые об этом говорю публично — цены на запросы снижены в пять раз.

И, вероятно, мы снизим их ещё, чтобы соответствовать нагрузкам с очень большим количеством запросов. Это одно изменение. Соотношение записей к чтениям по-прежнему высокое, но мы начинаем видеть сдвиг, если люди реально используют этот паттерн.

Alessio: Давайте поговорим о ценообразовании. Традиционно база данных берёт за хранение. Но теперь генерация токенов стоит так дорого, что реальная ценность хорошего поискового запроса гораздо выше — экономишь инференс дальше по цепочке.

Как вы это структурируете? И что люди готовы принять с другой стороны?

Simon Hørup Eskildsen: Ценообразование Turbopuffer в начале было очень простым. До Turbopuffer поисковые движки предлагали серверную модель: вот VM, вот почасовая стоимость.

А я просто сел с листом бумаги и сказал: если бы Turbopuffer был реально хорош — вот сколько бы это примерно стоило, с небольшой маржой. Так появились первые цены. Это было вайб-ценообразование.

И я ошибся. Ну, не совсем ошибся, но Turbopuffer не работал на первопринципных ценах. Когда Cursor пришёл на Turbopuffer... Я не знал ни одного венчурного инвестора. Не знал ничего о привлечении инвестиций.

Просто видел, что мой счёт GCP намного выше, чем счёт Cursor. Так что мы с Justine просто оптимизировали. К радости теперешних инвесторов — теперь мы прибыльные, именно потому что в начале было такое давление на цены. Мы работали с моей кредитки, потратили десятки тысяч долларов на вычисления, юристов, регистрацию компании — потому что мы просто не знали.

Если ты живёшь в Сан-Франциско, ты просто знаешь — идёшь и поднимаешь пре-сид раунд. А я на тот момент даже не слышал слова «пре-сид».

swyx: Когда у вас был Cursor и Notion — у вас не было финансирования?

Simon Hørup Eskildsen: С Cursor — не было. Да. К моменту Notion — Lachy уже был с нами.

Так что мы действительно сделали вайб-ценообразование на 100% из первых принципов, но реально система ещё не работала на первопринципном уровне. Так что мы делали всё возможное, чтобы хоть 5% маржи получить. Я не особо паниковал, потому что счёт Cursor тоже рос — они росли.

И мой долг и кредитный лимит... Я реально звонил в банк: мне нужен больший кредитный лимит! В общем, так было. Ценообразование — хранение, запись и запросы. Текущие цены — по сути те первые, заклеенные скотчем и слюнями, с попыткой приблизиться к марже на физическом железе.

В этом году вы увидите всё больше изменений цен от нас.

swyx: А насколько важен VPC-пиринг — ведь в AWS берут за исходящий трафик и всё такое.

Simon Hørup Eskildsen: Мы, наверное, специально это не выделяем. У нас есть энтерпрайз-план с базовой платой, потому что мы ещё не успели продумать SKU-ценообразование для всего.

Но вообще Turbopuffer можно использовать как SaaS — так делает Cursor. Можно в однотенантном кластере — только для вас, так делает Notion. И можно в BYOC — всё внутри VPC клиента, так, например, делает Anthropic.

swyx: Похоже, это лучшая вакансия CRO — прийти и помочь вам с этим.

Simon Hørup Eskildsen: Ну...

swyx: Помочь вам.

Simon Hørup Eskildsen: У Turbopuffer, не знаю какой по счёту — но примерно двенадцатым наймом был штатный CFO. У многих компаний, слышу, сотня сотрудников и нет CFO. С CFO всё как настоящий бизнес. Знаете...

swyx: Как у взрослого бизнеса.

Simon Hørup Eskildsen: Именно. Money Mike — он просто управляет финансами и кучей бизнес-вопросов. Он пришёл и разобрался с операционной стороной бизнеса.

COO-CFO — что-то среднее.

swyx: Раз уж заговорили о Lachy — мне любопытно, я встречал его, он явно отличный инвестор, теперь ещё и в Physical Intelligence. Я бы назвал его универсальным супер-ангелом — инвестирует во всё. И я всегда думаю: что привлекательнее — фокусироваться на DevTools, на базах данных, типа «я десять лет инвестирую в базы данных», или быть как Lachy, который может познакомить тебя со всеми нужными клиентами?

Simon Hørup Eskildsen: Отличный вопрос. Никто раньше не спрашивал. Почему Lachy? Потому что... Когда мы привлекали инвестиции, мы были немного в стрессе — один из конкурентов только что запустил что-то очень похожее на Turbopuffer.

Кто-то тогда дал мне совет: выбери человека, которому ты можешь просто позвонить без подготовки и быть полностью честным. И я — думаю, публично этого не говорил — просто позвонил Lachy и сказал: слушай, если к концу года не будет PMF, мы просто вернём тебе все деньги.

Просто мы с Justine не хотим работать над этим, если оно по-настоящему не работает. Хотим дать этому лучший шанс в этом году — пойдём ва-банк. Наймём людей. И будем честны со всеми. Когда я не знаю правил игры, я просто играю с открытыми картами.

Lachy оказался единственным, кого это не напугало. Он сказал: я никогда не слышал, чтобы кто-то такое говорил. Я тогда даже не знал, что такое сид- или пре-сид-раунд. Просто был с ним максимально честен. Спросил: Lachy, ты когда-нибудь инвестировал в компанию баз данных?

Он просто сказал: нет. И я подумал: я идиот? Но что-то меня к нему притянуло. Он невероятно искренний, честный — я чувствовал, что могу говорить абсолютно открыто. Это было идеальное совпадение тогда — и, честно говоря, остаётся таковым.

Он просто сказал: ладно, отлично. Это самое честное и безумное, что мне когда-либо говорили. Но именно поэтому...

swyx: Что в этом безумного? Мол, конкурент запустился, может не сработать?

Simon Hørup Eskildsen: Скорее просто: если не сработает — закрою лавочку к концу года.

Не знаю, может, это нормально. Он сказал, что необычно. Не знаю. Вот почему мы выбрали его, и он был невероятен. Другие, с кем мы говорили, были экспертами по базам данных — знали всё. А Lachy — нет. И это оказалось фантастическим преимуществом.

Мы с Justine и так знаем всё о базах данных. Люди, которых мы нанимаем — тоже. Нам нужен был кто-то, кто не знает о базах данных, не притворяется, что знает, и просто хочет помочь с кандидатами и клиентами. И он помог. У меня есть список инвесторов, с которыми у меня отношения, и Lachy — абсолютный лидер по количеству подпунктов того, что можно приписать ему.

Просто невероятно. Когда люди говорят «без эго» и «лучшее для фаундера» — даже мой юрист говорит: да, Lachy — самый приятный человек, которого вы найдёте.

swyx: Ладно, это самая восторженная рекомендация, которую я когда-либо слышал.

Alessio: Он это заслуживает.

Он очень особенный.

swyx: Да. Да-да. Ладно, потрясающе.

Alessio: Раз уж упомянули кандидатов — давайте поговорим о построении команды. Особенно в Сан-Франциско иногда кажется, что проще основать компанию, чем присоединиться к существующей. Мне любопытен ваш опыт — тем более что вы не живёте в SF постоянно и занимаетесь чем-то очень технически глубоким.

Simon Hørup Eskildsen: Присоединиться vs. основать — я никогда не думал, что стану фаундером. Turbopuffer начался как блог-пост, потом стал проектом, а потом почти случайно превратился в компанию. И теперь это всё больше компания. Это никогда не было целью.

Намерения были чистыми: просто — почему никто этого не сделал? Я хочу быть первым, кто это сделает. Некоторые фаундеры говорят: я бы никогда не смог работать на кого-то. Я так не чувствую. Просто: я хочу, чтобы это случилось. С людьми, с которыми приятно работать. И чтобы было весело. И всё это происходило очень естественно.

Это не было выбором «присоединиться vs. основать». Просто идея нашла меня в правильный момент.

Alessio: Ну, есть аргумент, что вам стоило бы пойти в Cursor. Как вы оценивали: собрать деньги и сделать компанию — или вот компания, которая бешено растёт, интересная техническая задача, можно просто построить это внутри Cursor, и не нужно шифровать и обфусцировать? Думали об этом?

Курсор мог стать местом работы.

Simon Hørup Eskildsen: Перед тем как взять небольшой чек от Lachy, я серьёзно посмотрел на себя в зеркало: реально ли я хочу это делать?

Потому что если возьму деньги — придётся делать по-настоящему. Я думаю об этом так: нужно быть достаточно одержимым, чтобы хотеть идти до конца. И этот разговор с самим собой — вот тогда я решил: ладно, это будет частью моего жизненного пути — построить эту компанию наилучшим образом, каким только смогу.

Потому что если я прошу людей присоединиться, прошу людей войти в кэп-тейбл — у меня абсолютная ответственность отдать всё. Мне кажется, не все воспринимают это так серьёзно. Может, я слишком серьёзно. Не знаю. Но это был очень осознанный момент.

И после него стало ясно: я делаю это и отдаю всё.

Alessio: Многие не воспринимают это так серьёзно. Но...

swyx: Давайте поговорим о вашей концепции P99-инженера. Все говорят о 10x-инженерах, кто-то предрекает инженерам безработицу — не знаю.

Но вы точно видите P99-инженера, и я хочу, чтобы вы об этом рассказали.

Simon Hørup Eskildsen: P99-инженер — это термин, который мы стали использовать внутри для обсуждения кандидатов и того, какую компанию хотим строить. Как и все, мы хотим компанию с высокой плотностью талантов.

Думаю, это уже стало банальностью. Команду Cursor я уважаю за то, что они пришли к этому из первых принципов: нам просто нужна talent-dense команда. А я видел команды, которые не были talent-dense, и видел контрфактические результаты — в большой компании такое неизбежно случается.

Для нас с Justine это было суперважно, и поддерживать это крайне сложно. Нам нужны были слова. Так что у меня есть документ «Traits of the P99 Engineer» — список буллет-поинтов. Я сверяюсь с ним после каждого собеседования, и на каждом разборе мы заканчиваем так:

Я говорю: «Я отклоняю этого кандидата, полностью, вне зависимости от обсуждения» — потому что хочу видеть, как люди борются за этого человека. По умолчанию — мы не нанимаем. По умолчанию — точно нет. И если все только: ну, может быть — это не тот человек.

swyx: Вы работаете по принципу: должен быть хотя бы один чемпион, который готов поставить карьеру на кон ради этого кандидата?

Simon Hørup Eskildsen: Карьеру на кон — может, перебор.

swyx: Может, стул, но...

Simon Hørup Eskildsen: Ну, скажем так — кто-то должен встать с двумя кулаками и быть готовым драться за кандидата.

Если хоть один человек такой — ок, давайте.

swyx: Да.

Simon Hørup Eskildsen: Не обязательно абсолютно все. Собеседования проверяют разные качества. И если кто-то выбивает мяч из парка по каждому — это довольно редко.

Но это реально важно. И вот в документе «Traits of the P99 Engineer» — много пунктов. Есть также черты P999-инженера и P9999-инженера. Длинный список.

swyx: Ок.

Simon Hørup Eskildsen: Дам пару примеров того, что мы ищем. P99-инженер имеет в прошлом опыт, когда он подчинил что-то своей воле — свою траекторию или что-то ещё.

Момент, когда он просто заставил компьютер делать то, что нужно. У него это случалось хотя бы раз в карьере. Желательно — несколько раз.

swyx: Приведите пример кого-то из ваших инженеров.

Simon Hørup Eskildsen: Приведу.

Мы выпустили штуку под названием ANN v3. Мы также работаем над v4 и v5. ANN v3 ищет по 100 миллиардам векторов с P50 около 40 миллисекунд и P99 около 200 миллисекунд. Может, кто-то ещё так делал — уверен, Google и другие. Но мы не видели такого ни у кого в публичном SaaS.

Это сделал Nathan — главный архитектор Turbopuffer. Он по сути подчинил себе софт: ПО не было на это способно, а он сделал его способным для конкретной нагрузки за 6–8 недель, с помощью команды. Это подчинение софта и x86 своей воле. Было невероятно наблюдать.

Хочется видеть такие моменты.

swyx: Это разве не P999?

Simon Hørup Eskildsen: Nathan, ну...

Alessio: Это круто, но P99 — как-то мало для такого.

Simon Hørup Eskildsen: Nathan — у него много девяток, да. Ладно, дальше. Ещё одна черта P99-инженера: он много времени проводит, глядя на карты.

Обычно это его любимый UX — просто смотреть на карты. Видели людей, которые сидят в телефоне и просто скроллят карту? Вы не смотрите на карты? Не смотрите?

swyx: Наверное, не мой уровень. Не знаю.

Simon Hørup Eskildsen: Вы сейчас просто провалились. А поезда? Вам нравятся поезда?

Нравятся?

swyx: Ну, недостаточно. Это такой, знаете... оружейный аутизм, я бы сказал.

Simon Hørup Eskildsen: Я обожаю смотреть на карты. Это мой любимый UX, просто... знаете, я люблю...

swyx: Много...

Alessio: ...разных случайных мест.

swyx: Типа...

Ну...

swyx: Знаете.

Alessio: Да. Ок. Вот, пожалуйста. Только не случайных мест, а как вы именно исследуете карты?

Simon Hørup Eskildsen: Нет-нет, это шутка.

swyx: Это смех аутиста — просто одержимость чем-то и изучение до мелочей.

Simon Hørup Eskildsen: Откуда это пошло: я как-то прочитал интервью с золотым медалистом IOI.

swyx: Угу.

Simon Hørup Eskildsen: И его спросили: чем занимаешься в свободное время? Он ответил: люблю смотреть на карты.

Я такой: меня поняли! Я обожаю скроллить — о, Канада такая большая. Где остров Баффина? Не знаю. Люблю это. В общем, черты P99: P99 — одержим. Просто видны проявления этого. У нас на собеседованиях в Turbopuffer несколько раундов, которые проверяют именно такие вещи.

Есть много других черт, но вот такие вещи мы ищем.

swyx: Расскажу кое-что — некоторые слушают мои DevRel-штуки. Я действительно думаю о DevRel как о картах. Рисуешь карту для людей — карта показывает, что считается общепринятыми географическими объектами, где проходят границы.

Она также показывает, чего ты не делаешь. Многие DevTools-компании пытаются сказать, что умеют всё. Но давайте честно: ваши три ориентира — вот здесь, все приходят сюда, потом сюда. Рисуешь карту и маршрут через неё.

Для меня так выглядит Developer Relations. Так что да, я мыслю подобным образом.

Simon Hørup Eskildsen: P99-инженер мыслит компромиссами. P99 очень чётко понимает: на Turbopuffer нельзя гонять высокотранзакционные нагрузки — задержка записи 100 миллисекунд.

Это явный компромисс. P99-инженер отлично формулирует компромиссы каждого решения. Что в вашем случае и есть карта.

swyx: Да-да. Мой мир. Мой мир.

Alessio: Как вы примиряете эти вещи — «подчинить компьютер своей воле» и «компромиссы»?

Иногда кажется: вот компромиссы, но P999-инженер скажет — это на самом деле не компромисс, потому что мы можем сделать то, чего никто не делал, и это будет работать.

Simon Hørup Eskildsen: Я думаю о «подчинении воле» так: берёшь «математику на салфетке» — сто машин, столько-то терабайт дисков, столько-то пропускной способности.

Считаешь как в школе: сколько QPS мы должны выжать. Похоже на моё вайб-ценообразование. А потом смотришь на реальную систему и видишь: мы отстаём в 10 раз. «Подчинение воле» — это приближение софта к первопринципной линии.

P99 может даже пересечь эту линию — найти оптимизации, которых не было в первопринципных расчётах. Так что это про то, чтобы... 100 миллисекунд P99 к S3 — это когда кто-то по-настоящему высокоагентный едет в Сиэтл, находит команду S3 и говорит: как мы сделаем это за 10?

Ну, мы пока не об этом говорим, но да.

swyx: Какое будущее у Turbopuffer?

Simon Hørup Eskildsen: Первый акт Turbopuffer — векторный поиск, только он. Второй акт — полнотекстовый поиск. Сегодня у Turbopuffer довольно продвинутый полнотекстовый движок.

Мы обгоняем Lucene на некоторых запросах — в частности, на очень длинных, под которые оптимизировались, потому что именно такие текстовые запросы мы видим сегодня: сгенерированные или дополненные LLM. И мы видим их на вебмасштабных датасетах — кто-то ищет длинную текстовую строку по всему Common Crawl.

Мы обгоняем Lucene на некоторых из этих бенчмарков и ожидаем, что будем обгонять на всё большем количестве запросов. Это производительность и масштаб. Сейчас мы работаем над всё большим количеством фич для полнотекстового поиска — люди ожидают много функциональности.

А полнотекстовый поиск по-прежнему очень ценен. Зайдите в приложение, нажмите Cmd+K и введите «si». Эмбеддинговый поиск может решить: это что-то согласительное, потому что «sí» — это «да» по-испански.

Alessio: И по-итальянски тоже.

Simon Hørup Eskildsen: А полнотекстовый поиск — это префикс, может быть, документа «все причины, по которым я ненавижу Simon».

Это совершенно другое. Такое дополнение к тому, как работает человеческий мозг, маппинг данных на пользователя — очень важно. Но это требует кучи фич. И этот функциональный грайнд — мы в нём по уши. Каждый месяц в ченджлоге всё больше фич полнотекстового поиска.

Мы видим, что люди переходят с традиционных поисковых движков на Turbopuffer. Это большой фокус на этот год. Другой фокус — масштаб. Мы видим всё больше компаний, которые хотят искать по датасетам уровня Common Crawl.

Как внутренним, так и внешним — запросы вроде 100 миллиардов векторов или документов одновременно. Это непросто, и мы хотим сделать дешевле и быстрее. Мы выпустили ANN v3, о котором говорили. Работаем над ANN v4 и уже спланировали ANN v5. А для полнотекстового поиска — работаем над кучей фич, что-то вроде FTS v3, но всё будет выходить инкрементально.

Это крупные вещи. А ещё — наш дашборд. Кто-нибудь из вас заходил в дашборд Turbopuffer? Там почти ничего нет. Выглядит так, будто фаундер два года назад сел и написал минимальный дашборд, потом следующие два года другие что-то добавляли, потом SSO и прочее для галочки.

Может, так и было. Но я хочу вернуть phpMyAdmin. Помните? Было же классно. Мне очень хочется этой интеграции софта и железа — между дашбордом-консолью и самой базой данных.

Много чего ещё выйдет в ближайшие пару лет. Мы поговорили о ценах и прочем. Но вот главные направления сейчас.

swyx: Вы говорите об эпохах Turbopuffer. Я должен спросить: да, есть то, над чем вы работаете в этом году, но наверняка в вашей голове уже следующая фаза.

Simon Hørup Eskildsen: Третий акт.

swyx: Да. Четвёртый. Да.

Simon Hørup Eskildsen: Пятый акт.

swyx: Что скажете о кандидатах — не обязательно определяться. Но вы-то знаете.

Simon Hørup Eskildsen: Скажу так: если хочешь построить большую компанию баз данных — со временем нужно реализовать практически каждый план запросов. Потому что когда данные в базе, со временем ожидаешь не только поиск, но и «хочу агрегировать эту колонку, хочу сджойнить эти данные» — всё.

Но когда ты стартап, единственный ров — это фокус. Нужно выстраивать последовательность и не увлекаться. Некоторые конкуренты увлеклись и перенапряглись. И я постоянно говорю команде — мы сегодня утром завтракали с CTO и главным архитектором, обсуждали: о чём мы скорее всего пожалеем в конце года — что пытались сделать слишком много.

Кандидаты на третий акт — возможно, простые OLAP-запросы. Мы видим людей, которые хотят делать трейсы, логирование. Простые кейсы. Может, какие-то временные ряды.

Разные вещи можно делать с Turbopuffer. Но сейчас — если вы пытаетесь использовать Turbopuffer не для поиска, скорее всего, не стоит. Хотя бывает — в какой-то момент Cursor перенёс 20 терабайт данных из Postgres в Turbopuffer, потому что оно работает, и для этих конкретных планов запросов — хорошо.

Они перенесли всё, чтобы отложить шардирование. Мы ищем такие паттерны у клиентов — что может стать будущим актом Turbopuffer, прежде чем полноценно удвоиться на этом. Но сегодня Turbopuffer — для тех, кому поиск критически важен.

Потом мы, возможно, добавим много ускоренных запросов к этому, но это не должно быть главной причиной приходить к нам на данный момент.

swyx: Вы не упомянули одну вещь, которую я ожидал — графовые запросы. Графовая база данных. Вы можете это тривиально повторить на том, что уже есть?

Simon Hørup Eskildsen: Мы видим, что некоторые люди так делают.

swyx: Потому что у вас параллельные запросы и... это, по сути, то же самое.

Simon Hørup Eskildsen: Именно. Некоторые так делают. Под капотом — это просто KV-хранилище, а поверх мы предоставляем абстракции. Мы видим это. И наш роадмап — это база данных, которая соединяет ИИ с огромными объёмами данных. Путь к этому — делать вещи в правильном порядке, и хороший стартап — это именно про порядок.

Наши клиенты — P99, и они скажут нам, что им нужно дальше. Некоторые уже строят графы, и если им понадобится больше фич графовых баз — они будут стучать к нам в дверь, и мы расставим приоритеты.

swyx: Чай. Давайте про чай. Вы любезно подарили нам ваш любимый чай.

Это Yabu Keita Kamairicha из The Green Tea Shop. Верно? Расскажите о своей любви к чаю.

Simon Hørup Eskildsen: Да, мы до записи как раз обсуждали кофеин. Особенно в поездках вроде этой, в Сан-Франциско, я потребляю много кофеина. Но этот зелёный чай — мой любимый источник.

У меня Airtable с 200 чаями, которые я пробовал за последние 15 лет, и этот — мой фаворит. Есть шесть типов чая. Мне нравится зелёный, обычно предпочитаю китайский. Японский зелёный обычно не люблю. Но есть одна маленькая префектура в Японии, которая специализируется на том, чтобы делать японский чай китайским способом, и это просто великолепно.

А ещё интересное в мире чая: этот конкретный чай можно найти в сотнях мест, но все закупают у разных семей на какой-нибудь горе, где растут кусты чайного дерева. И эта японка в Торонто из The Green Tea Shop — она нашла реально хорошую семью.

Лучшее время для покупки — через пару месяцев, когда будет весенний урожай. Сейчас чай немного старый. Я обожаю весну ради свежего чая. Надеюсь, вам понравится. Но сейчас не сезон.

swyx: Не в сезоне. Я даже не знал, что у чая есть сезоны.

Это, конечно, показывает мою необразованность. Но это связано с тем же — любовь к картам, одержимость, внимание к деталям во всём, что делаешь. Отлично.

Alessio: Замечательно. Как мы говорили, у нас в Kernel есть мгновенный кипяток. Так что любитель чая может заходить в любое время.

Simon Hørup Eskildsen: У меня есть набор, в котором я вожу маленький термометр — Thermoworks.

В прошлую пятницу на демо-дне — у меня есть правило: если демо мало, оставшееся время я заполняю рассказом о чём-нибудь совершенно абсурдном, чтобы мотивировать людей реально показывать. И в тот раз я 20 минут рассказывал про свой Airtable и весь мой чайный дорожный набор, включая термометр.

Потому что приезжаешь куда-то — есть только кипятильник, нельзя получить нужную температуру. Этому чаю нужно 80 градусов, и... ладно, извините.

Alessio: У нас дома электрочайник с регулировкой температуры.

swyx: Я бы это смотрел. Вам стоит завести YouTube-канал — но не про поиск, а про чай и другие бренды.

Просто чай.

Simon Hørup Eskildsen: Не думаю, что смог бы долго про это говорить. Но одна вещь, которую я начал делать. Вы знаете Sam Lambert из PlanetScale?

swyx: Конечно.

Simon Hørup Eskildsen: Так вот...

swyx: Очень прямолинейный парень.

Simon Hørup Eskildsen: Обожаю его. На прошлой неделе мы вышли в X Live и просто проболтали час. Думаю, повторим.

Да. Наверное, ещё что-нибудь сделаем. Не знаю, как назовём. Может, P99 Live или P99 Pod.

swyx: P Pod.

Simon Hørup Eskildsen: P Pod.

swyx: Круто. Спасибо огромное за ваше время. Знаю, вам нужно бежать. Но это было здорово — вы явно очень увлечённый и харизматичный человек. Уверен, после этого подкаста к вам придут P99-инженеры.

Да.

Simon Hørup Eskildsen: Огромное спасибо, что пригласили. Было очень приятно.

Обсуждение этого выпуска