← Дайджест от 1 октября 2026
Инструменты
2 источникаHN 280
2 источникаHN 280Сервис поиска turbopuffer заявил, что отдельная база под векторы больше не нужна
Разработчик сервиса векторного поиска turbopuffer опубликовал разбор под названием «RIP, vector database»: отдельная база под векторы — представления текста в виде чисел, по которым ищут по смыслу, — как продукт себя исчерпала.
Аргумент прикладной: поиск по смыслу почти никогда не нужен в чистом виде. В реальных запросах к нему всегда прилагаются фильтры по владельцу, дате и правам доступа, плюс обычный поиск по словам. И всё это дешевле делать в одном хранилище, чем сшивать две базы и держать их синхронными.
В обсуждении на Hacker News спорят о конфликте интересов: вывод публикует компания, которая сама продаёт хранилище с объединённым поиском.
Что говорят
sreekanth850Hacker News
Для корпоративного поиска я почти не вижу смысла в чистой векторной БД. Мы построили движок на SQL с нативной поддержкой векторов: векторное сходство — лишь один примитив рядом с полнотекстовым поиском, фильтрами, джойнами и сортировкой, а ACL, версии документов, категории и временные фильтры становятся обычными предикатами, а не костылём поверх векторного хранилища.
gopalvHacker News
Это прямая параллель с тем, как строили индексы Postgres и MySQL: вы перешли от паттерна Postgres к паттерну MySQL. Разница в том, что Postgres оптимизировали под чтение, а MySQL — под запись и переиндексацию.
blakeashleyjrHacker News
Это спор Postgres против InnoDB, только 10 лет спустя: постинги указывали на физическое место (слот ANN), поэтому каждая перебалансировка SPFresh переписывала все индексы, затрагивающие документ. InnoDB решил это ссылками на первичный ключ ценой лишнего поиска при чтении — интересно, сколько стоит этот лишний поиск, когда он не прыжок по B-дереву, а GET в S3.