Google поднял ScaNN в AlloyDB до 10 млрд векторов и получил в своих тестах p95 не выше 51 мс при recall 95%. Для команд, которые сейчас проектируют RAG, это меняет стартовую архитектуру: отдельная vector DB больше не должна появляться в схеме по умолчанию. Но и вычеркивать ее рано, потому что Google раскрыл масштаб поиска, а не полную стоимость и поведение системы под рабочей нагрузкой.
Что именно показал Google
В блоге Google Cloud пишет, что ScaNN теперь работает с более чем 10 млрд векторов. Результат получен на новом четырехуровневом дереве, которое пока находится в preview. Раньше древовидный индекс AlloyDB ограничивался двумя или тремя уровнями: дальнейший рост увеличивал вычислительную нагрузку при построении и обходе индекса, а выборка для обучения могла упираться в доступную память.
Четвертый уровень сужает пространство поиска. По оценке Google, сложность обхода снижается с O(N^1/2) для двух уровней и O(N^1/3) для трех до O(N^1/4). Чтобы удержать качество поиска, используются Top-K branch, SOAR, корректировка центроидов и сбалансированная форма дерева. При нехватке памяти система уменьшает обучающую выборку, стараясь сохранить баланс между точностью и производительностью.
Итог внутреннего теста Google звучит убедительно: более 10 млрд векторов, p95 до 51 мс, recall 95%. Это уже не демонстрация на каталоге из нескольких миллионов объектов. По крайней мере по масштабу AlloyDB претендует на retrieval-нагрузку, ради которой раньше в архитектуру без долгих споров добавляли специализированную систему.
Почему vector DB пока нельзя просто удалить из схемы
Главное ограничение публикации находится не в результате, а в том, чего рядом с ним нет. Google не приводит в посте стоимость инфраструктуры для такого теста, размер индекса, время его построения и объем потребляемой памяти. Нет данных о скорости обновления 10-миллиардного корпуса, влиянии вставок и удалений на задержку, а также о поведении поиска при фильтрации по полям.
Для operational database это не мелочи. Если данные меняются, новый объект должен попадать в retrieval без длительного окна переиндексации. Поэтому цифра 51 мс отвечает на вопрос «можно ли быстро искать в большом индексе», но не отвечает на более дорогой вопрос «можно ли так жить каждый день».
Recall 95% тоже нельзя оценивать отдельно от сценария. Для одного продукта это приемлемый обмен точности на задержку, для другого недостающие пять процентов окажутся причиной держать более дорогую конфигурацию или отдельный поисковый слой. Сам Google описывает механизм, который при ограничениях памяти сокращает обучающую выборку. Значит, баланс памяти, качества и стоимости нужно проверять на собственном распределении данных, а не переносить из блога в финансовую модель.
Выигрыш находится не только в миллисекундах
Если операционные данные уже хранятся в AlloyDB, потенциальная экономия возникает за пределами самого поиска. Один контур означает, что команде не нужно отдельно синхронизировать записи и векторы, отслеживать рассогласование двух систем и эксплуатировать еще один сервис. Именно здесь универсальная база может выиграть у профильной vector DB, даже если та окажется быстрее в изолированном тесте.
Это не одиночный маневр Google. InfoWorld писал, что AWS добавляет native vector search в DynamoDB именно для снижения сложности, связанной с отдельными векторными базами. Сам Google продвигал AlloyDB как AI-native database с vector и hybrid search. Рынок баз данных явно хочет вернуть retrieval внутрь operational layer. Специализированным игрокам теперь недостаточно продавать быстрый nearest-neighbor search: им придется доказывать, что выигрыш покрывает цену отдельного контура.
Для архитектора вывод практический. AlloyDB ScaNN нужно включить в сравнительный тест рядом с профильными vector DB и считать не только цену запроса. В TCO должны попасть инфраструктура индекса, перенос и синхронизация данных, мониторинг, резервирование и труд команды на эксплуатацию. На малом корпусе отдельная система могла выглядеть избыточной и раньше. Теперь этот аргумент стоит проверять и на масштабе 10 млрд векторов, пока только в preview и на основании внутренних тестов Google.
Следующий маркер стоит искать не в очередном рекорде масштаба. Нужны результаты четырехуровневого ScaNN после выхода из preview: время построения индекса, его стоимость по памяти и хранению, скорость обновлений и p95 с recall под фильтрами. Если Google опубликует эти четыре показателя на сопоставимом масштабе, отдельная vector DB из обязательного слоя действительно превратится в осознанную опцию.