Pinecone выпускает Pg_pinecone — расширение поиска для Postgres с открытым исходным кодом

Pinecone выпустила pg_pinecone 27 октября 2026 года. Это расширение для Postgres с открытым исходным кодом под лицензией Apache 2.0. Оно переносит в столбцы pgvector, которые приложения уже хранят в базе, поисковый движок для векторов, который, по словам компании, используется ею в промышленных масштабах. В тестах, проведённых компанией, собственный индекс расширения для 1 миллиона векторов размерности 768 занимал 136 МБ, тогда как индекс HNSW — 2,0 ГБ для halfvec и 4,1 ГБ для векторов полной точности.

О выпуске сообщили в публикации с анонсом, подготовленной Харшитой Даддалой и Энтони Маханной. Как говорится в публикации, обычно для поиска векторов в Postgres используют графовый индекс, например HNSW. Для поддержания производительности ему требуется всё больше памяти, он долго строится, а точность поиска с фильтрацией снижается. Если запрос ограничен данными одного пользователя или арендатора, графовый индекс может вернуть меньше строк, чем указано в LIMIT запроса. В pg_pinecone фильтр применяется прямо во время поиска, что, по словам Pinecone, позволяет даже при узкой области поиска получать полный набор результатов; при использовании движка по умолчанию данные не покидают Postgres.

Три движка для одного индекса

pg_pinecone работает с векторными столбцами, уже хранящимися в pgvector. Приложение подключается к Postgres по-прежнему и отправляет тот же SQL-запрос, например ORDER BY embedding <=> $1 LIMIT 10. Таблицы, включая полные векторы, остаются на месте, а Postgres продолжает быть системой учёта данных.

Для каждой таблицы используется один из трёх движков. Собственный движок, выбранный по умолчанию, полностью строит индекс и выполняет поиск в нём внутри Postgres — без учётной записи Pinecone, ключа API и сетевых вызовов. Движок pgvector выполняет поиск по уже существующему индексу pgvector — HNSW или IVFFlat. В репозитории на GitHub проекта говорится, что он подходит для таблиц, в которых уже есть индекс pgvector и не применяется фильтрация. Удалённый движок направляет поисковые запросы к бессерверному индексу в управляемом сервисе Pinecone и предназначен для таблиц, которые переросли возможности одного сервера Postgres. Чтобы переключить таблицу на другой движок, достаточно одного вызова pinecone.set_engine(); запросы менять не нужно, а переключение в любой момент можно отменить.

Как работает поиск в собственном движке

Как и HNSW в pgvector, собственный движок использует алгоритм приближённого поиска ближайших соседей, но вместо графа применяет инвертированный файловый индекс, группирующий похожие векторы в кластеры. Каждый вектор хранится в виде квантованного кода RaBitQ: примерно один бит на измерение и несколько корректирующих значений. В публикации этот метод приписывают Гао и Лонгу и их работе для SIGMOD 2024. Коды для каждого кластера упакованы вместе, поэтому при поиске считываются несколько смежных страниц, а не выполняются переходы по графу.

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

Фильтрация выполняется непосредственно во время поиска. По словам Pinecone, HNSW в pgvector применяет фильтр после поиска ближайших соседей, то есть условие WHERE проверяется уже после него. Поэтому при узком фильтре отбрасывается большинство кандидатов, а итеративное сканирование восполняет их нехватку за счёт увеличения времени выполнения и, при использовании relaxed_order, снижения точности. Собственный движок хранит значение столбца фильтра рядом с кодом каждой строки и во время построения индекса подсчитывает количество строк для каждого значения. Для узких фильтров — по умолчанию таких, которым соответствуют не более 3% строк, — движок сначала применяет фильтр, сканируя все подходящие строки во всех кластерах и оценивая каждую по полному вектору, что обеспечивает точные результаты. Для более широких фильтров он использует одноэтапную фильтрацию: ищет не более чем в половине ближайших кластеров и проверяет фильтр внутри каждого кластера до оценки строк.

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

Результаты тестирования, представленные Pinecone

Pinecone сравнила собственный движок с индексом HNSW в pgvector, используя векторы полной точности и halfvec, на 1 миллионе векторов wiki_dpr размерности 768. Тесты проводились на экземпляре AWS r6id.4xlarge с 16 виртуальными процессорами и 128 ГБ оперативной памяти. Задержку при поиске без фильтра, время построения индекса и его размер измеряли в одном сеансе на PostgreSQL 17; поиск с фильтрацией — в другом сеансе на PostgreSQL 18; конфигурацию с ограничением памяти — в третьем. Задержка указана как медиана p50 при k=10 и одном клиенте. Компания сообщила, что полная конфигурация тестов и команды для их повторного запуска приведены в README тестового набора в репозитории.

Для 1 миллиона векторов Pinecone указала размер собственного индекса 136 МБ против 2,0 ГБ у HNSW с halfvec и 4,1 ГБ с векторами полной точности. При поиске без фильтра компания сообщила о задержке 1,3 мс при полноте 0,95 против 1,7 мс у HNSW с halfvec и 2,7 мс с векторами полной точности; при полноте 0,99 задержка составила 2,3 мс против 4,7 мс и 6,7 мс соответственно. При фильтре, соответствующем 10% строк, собственный движок, по данным Pinecone, достиг полноты 1,000 за 12,3 мс при одноэтапной фильтрации, тогда как HNSW с итеративным сканированием обеспечил максимальную полноту 0,920 за 5,9 мс. При фильтре 1% сообщалось о полноте 0,981 за 8,3 мс. По опубликованным данным, построение индекса занимало 45 секунд для собственного движка, 62 секунды для HNSW с halfvec и 79 секунд для векторов полной точности.

Доступность и дополнительные возможности Pinecone

Для работы pg_pinecone требуются PostgreSQL 17 или 18, права суперпользователя и установленный на сервере pgvector. Расширение можно установить из готовых релизов на GitHub или из образа pineconeteam/pg_pinecone на Docker Hub. В README этот образ описан как образ pgvector/pgvector с добавленным pg_pinecone; он публикуется с отдельным тегом для каждой основной версии Postgres, например 0.11.0-pg17. Для запуска удаленного движка также необходимо загрузить расширение через shared_preload_libraries. При настройке создаются расширения vector и pg_pinecone, а индекс формируется вызовом pinecone.create_index(). Проект также можно собрать из исходного кода с помощью набора инструментов Rust и cargo-pgrx 0.19.2.

При наличии необязательного ключа API Pinecone удаленный движок в фоновом режиме синхронизирует эмбеддинги с индексом Pinecone, а поиск продолжает выполняться в Postgres, пока копирование не завершится. В публикации описаны еще три необязательные функции: embed() обращается к сервису инференса Pinecone, чтобы преобразовывать текст в эмбеддинги из SQL; функция работает как с собственным, так и с удаленным движком, а первая сборка покрывается бесплатным тарифом Pinecone; полнотекстовый поиск BM25 выполняется параллельно с векторным поиском в той же таблице, а запросы BM25, векторные или гибридные запросы отправляются из SQL; rerank() переупорядочивает результаты с наивысшими оценками с помощью моделей переранжирования Pinecone.

В документации на docs.pinecone.io описаны установка, движки хранения, переключение между движками и полнотекстовый поиск; в репозитории также представлены справочник по SQL, руководство для операторов и руководство по аварийному восстановлению. Pinecone назвала этот выпуск первым в истории проекта, сообщила, что поддерживает pg_pinecone и проверяет каждый запрос на включение изменений, а также заявила, что составит открытую дорожную карту проекта на основе отзывов, оставленных в issues на GitHub, в сообществе Discord и на ежемесячных приемных часах.