pgvector

pgvector — это открытое расширение, превращающее обычную базу данных PostgreSQL в полноценное векторное хранилище, добавляя тип столбца `vector`, операторы расстояния (`<->` для евклидова, `<=>` для косинусного, `<#>` для скалярного произведения) и типы индексов (IVFFlat и HNSW) для быстрого приближённого поиска ближайших соседей. Почему это важно для AI/SaaS-разработчиков: это позволяет командам добавить семантический поиск или RAG-извлечение в продукт, не внедряя вторую систему баз данных. Большинство SaaS-бэкендов уже используют Postgres для своих основных реляционных данных (пользователи, подписки, заказы); pgvector означает, что эмбеддинги могут жить в той же базе данных, даже в той же таблице, прямо рядом со строками, которые они описывают, — объединяться обычным SQL `JOIN`, фильтроваться обычным условием `WHERE` и покрываться теми же резервными копиями, репликацией и транзакционными гарантиями, что и всё остальное. Эта операционная простота — главная причина взрывного роста применения pgvector в 2024–2026 годах: на одну движущуюся часть меньше, на один счёт от поставщика меньше, на одну задачу синхронизации данных меньше для поддержания согласованности векторного хранилища с источником истины. Как это работает: после `CREATE EXTENSION vector;` вы добавляете в таблицу столбец вроде `embedding vector(1536)`, заполняете его через своё приложение (вызов API эмбеддингов, `UPDATE` строки) и строите индекс — `CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);` — для быстрого приближённого поиска, когда количество строк превышает несколько десятков тысяч (ниже этого порога последовательное сканирование зачастую достаточно быстро и проще). Запросы выглядят как обычный SQL: `SELECT id, body FROM articles ORDER BY embedding <=> $1 LIMIT 5;` возвращает 5 ближайших соседей вектора запроса по косинусному расстоянию. Поскольку это просто Postgres, вы можете сочетать векторное сходство с реляционной фильтрацией и фильтрацией по метаданным в одном запросе — не нужен отдельный API фильтрации, нет задержки eventual-consistency между двумя системами. Компромиссы по сравнению со специализированными векторными базами данных: при очень большом масштабе (десятки миллионов векторов с высокой пропускной способностью запросов) или когда нужна мультирегиональная репликация, настроенная специально под векторные нагрузки, специализированные хранилища вроде Pinecone или Qdrant обычно всё ещё превосходят pgvector по производительности и масштабируемости. Разбор примера: SaaS для управления проектами добавляет функцию «AI-поиск». Вместо развёртывания Pinecone они добавляют `embedding vector(1536)` в существующую таблицу `tasks`, заполняют её задним числом пакетной задачей, вызывающей API эмбеддингов, и строят HNSW-индекс. Эндпоинт поиска становится: `SELECT * FROM tasks WHERE workspace_id = $1 ORDER BY embedding <=> $2 LIMIT 10;` — семантический поиск, бесплатно уважающий существующую изоляцию арендаторов на уровне строк, выпущенный в одной миграции и одном эндпоинте.