turbopuffer: как построить поисковую базу поверх S3 (Рубрика #Architecture) Посмотрел разговор Gergely Orosz с Simon Eskildsen, сооснователем и CEO turbopuffer. Формально выпуск про инфраструктуру поиска для AI-продуктов, но для меня он прежде всего про старую инженерную дисциплину: сначала посчитать физику и экономику системы, а уже потом верить бенчмаркам. До turbopuffer Simon восемь лет занимался инфраструктурой Shopify. Там он собрал Napkin Math - таблицу с пропускной способностью DRAM и NVMe, задержками S3 и стоимостью разных видов хранения. Если расчёт говорит «10 мс», а тест показывает 10 секунд, нужно не выбирать соседнюю базу, а понять, где потерялись три порядка: в плане запроса, сети, распределении работы по узлам или самом эксперименте. turbopuffer вырос именно из такого несоответствия. Делая рекомендации для Readwise, Simon оценил, что хранение и поиск по векторам обойдутся примерно в $30 тысяч в месяц — при $5 тысячах на всю остальную инфраструктуру компании. По его словам, экономика продукта не сходилась, и функцию не запустили. Тогда он задал более полезный вопрос: обязательно ли постоянно держать все векторы в дорогой памяти и на реплицированных SSD? Ответом стала база, где все постоянные данные лежат в объектном хранилище (object storage), а вычислительные узлы не держат собственного состояния. Упрощённо векторы собираются в кластеры, отдельно хранится индекс центроидов, а запрос загружает только ближайшие кластеры. Горячие данные попадают в память, тёплые - в NVMe-кэш, холодные читаются из S3. Это не бесплатный трюк: запись может занимать до 200 мс, а холодные запросы иногда уходят в сотни миллисекунд. Но для поиска обычно важнее высокая пропускная способность, надёжность и цена хранения, чем транзакционная задержка каждой записи. turbopuffer сознательно платит более медленными записями и редкими холодными запросами за дешёвое хранение основной массы данных. Особенно хороша история первого клиента. По словам Simon, им стал Cursor, пришедший после запуска MVP в Twitter. Simon прилетел в Сан-Франциско и начал не с продажи, а с разбора чужой проблемы Postgres: autovacuum не успевал, и база читала таблицу вместо нужного index scan. Эта помощь создала доверие; затем Cursor перенёс нагрузку на turbopuffer за одну-две недели. По данным компании, первый счёт оказался на 95% ниже последнего счёта предыдущего поставщика. Это не независимый бенчмарк, но продуктовый урок сильный: критическую инфраструктуру покупают не по красивой диаграмме, а у команды, которая понимает весь контур отказов и стоимости. Для меня главный вывод: мышление от первых принципов не заменяет измерения - оно делает их осмысленными. Сначала прикидываем пределы железа и стоимость нагрузки, затем строим простейшую систему с нужными инвариантами и только после этого оптимизируем реальную работу. turbopuffer интересен не потому, что «S3 победил базы данных», а потому, что команда отказалась платить за свойства, которые её поиску не нужны. #Software #Data #Architecture #Infrastructure #Engineering #AI