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

Pinecone випустила pg_pinecone 27 жовтня 2026 року. Це розширення для Postgres із відкритим вихідним кодом, ліцензоване за Apache 2.0, яке переносить у стовпці pgvector, де застосунки вже зберігають дані, пошуковий рушій для векторів, що, за словами компанії, працює в її масштабній інфраструктурі. У тестах продуктивності, про які повідомила компанія, нативний індекс розміром для 1 мільйона векторів із 768 вимірами становив 136 МБ проти 2,0 ГБ для HNSW на halfvec і 4,1 ГБ для векторів повного розміру.

Про випуск повідомили в дописі-анонсі, який підготували Harshita Daddala й Anthony Mahanna. Як зазначено в дописі, зазвичай для пошуку векторів у 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: приблизно один біт на вимір плюс кілька коригувальних значень. У дописі зазначено, що цей метод запропонували Gao і Long у роботі для SIGMOD 2024. Коди кожного кластера зберігаються разом, тож під час пошуку система читає кілька суміжних сторінок, а не переходить від вузла до вузла графа.

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

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

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

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

Pinecone порівняла нативний рушій з індексом HNSW у pgvector, використовуючи вектори повного розміру та halfvec, на 1 мільйоні векторів wiki_dpr із 768 вимірами. Тести проводили на інстансі AWS r6id.4xlarge із 16 vCPU та 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 та перевіряють кожен запит на злиття, а також зазначили, що сформують публічну дорожню карту на основі відгуків, надісланих через запити GitHub, спільноту Discord і щомісячні години відкритого спілкування.