LanceDB загрузил 100 тысяч эмбеддингов OpenAI в 22 раза быстрее, чем pgvector, в то время как pgvector обрабатывал ту же нагрузку от восьми одновременных клиентов в 1,8 раза быстрее. Разрыв в задержке одного потока и эффективности хранения также склонился в пользу LanceDB, предоставляя разработчикам возможность обоснованного выбора векторного хранилища на основе данных.

Почему бенчмарк важен именно сейчас

Векторный поиск перешел из исследовательских лабораторий в рабочие сервисы, такие как рекомендательные системы и генерация с дополнением извлечением (RAG). Большинство команд уже используют PostgreSQL, поэтому расширение pgvector обещает поиск по сходству без необходимости внедрения новой инфраструктуры. Однако специализированные хранилища, такие как LanceDB, заявляют о более низкой задержке и более дешевом хранении. Командам приходится выбирать между подходом «добавить к тому, что уже есть» и «запустить специализированный движок» — это решение влияет на стоимость и производительность по мере роста наборов данных и частоты запросов.

Как проводилось тестирование

Обе системы индексировали одни и те же 100 тысяч векторов размерностью 1536 каждый, созданных с помощью модели эмбеддингов OpenAI. Мы измеряли скорость загрузки, использование диска, задержку однопоточных запросов и пропускную способность при работе восьми одновременных клиентов.

Результаты прямого сравнения

  • Скорость загрузки — LanceDB показала преимущество в 22 раза.
  • Занимаемое место на диске — LanceDB хранила векторы примерно в три раза компактнее, чем pgvector.
  • Задержка одного потока — запросы в LanceDB выполнялись примерно в два раза быстрее.
  • Масштабируемость при параллельной работе — при восьми параллельных клиентах pgvector обеспечила пропускную способность в 1,8 раза выше, чем LanceDB.

Архитектурные причины различий

LanceDB — это встроенная (embedded) библиотека, которая работает внутри процесса Python, в котором запущено приложение. Все операции выполняются внутри процесса, поэтому данные никогда не пересекают сетевой барьер, а обновление индекса происходит с минимальными накладными расходами. Такая архитектура отлично подходит для однозадачных нагрузок, но упирается в потолок, когда несколько потоков Python начинают конкурировать за Global Interpreter Lock (GIL), который блокирует истинное параллельное выполнение байт-кода Python.

pgvector расширяет PostgreSQL на стороне сервера. Каждое клиентское соединение запускает отдельный серверный процесс, полностью обходя GIL. Планировщик PostgreSQL решает, как выполнить поиск по сходству, а сервер может запускать множество процессов для обработки параллельных запросов. Такая изоляция объясняет лучшую масштабируемость под нагрузкой.

Особенности фильтрации и планирования запросов

Реальные RAG-конвейеры часто сочетают векторное сходство с традиционными фильтрами (например, WHERE user_id = 42). LanceDB применяет предварительный фильтр (prefilter), который ведет себя предсказуемо от запуска к запуску. pgvector полагается на планировщик запросов PostgreSQL, который может выбрать быстрый поиск по индексу или перейти к более медленному полному сканированию в зависимости от статистики. Выполнение команды ANALYZE после массовой загрузки таблицы pgvector обновляет эту статистику; без неё полнота поиска (recall) может упасть почти до нуля, что фактически сломает поиск.

Когда стоит выбрать каждый из вариантов

Выбирайте pgvector, если

  • Ваш стек уже включает PostgreSQL, и вы хотите избежать добавления еще одного сервиса.
  • Вы ожидаете много одновременных пользователей или API-вызовов.
  • Вам важны гарантии ACID и привычные инструменты администратора БД (DBA).

Выбирайте LanceDB, если

  • Ваш рабочий процесс — это ML-конвейер, в который часто поступают новые эмбеддинги.
  • Вам нужен максимально быстрый путь записи и низкая задержка для агентов, обрабатывающих одиночные запросы (например, чат-ботов).
  • Стоимость дискового пространства имеет значение, и вы можете смириться с ограничением производительности в одном потоке.

Итог: Если важнее всего чистая скорость загрузки, минимальный объем хранилища и задержка одиночного запроса, побеждает LanceDB. Если вам необходимо обслуживать множество пользователей одновременно и вы полагаетесь на существующее развертывание PostgreSQL, преимущество pgvector в параллелизме делает его более надежным выбором. Используйте данные этого бенчмарка, чтобы подобрать хранилище под наиболее критическую метрику вашего продукта.