Прежде чем сравнивать конкретные решения, разберёмся, почему обычные базы данных не справляются с задачей поиска по эмбеддингам. Традиционные реляционные базы данных - PostgreSQL, MySQL, ClickHouse - проектировались для работы со структурированными данными: числами, строками, датами. Их индексы (B-tree, Hash) оптимизированы для точного совпадения или диапазонных запросов: «найди все заказы за прошлый месяц» или «найди пользователей с именем Иван».

Векторный поиск работает принципиально иначе. Здесь нет точного совпадения - нужно найти записи, «ближайшие» к заданному вектору в многомерном пространстве. Вектор эмбеддинга - это массив из сотен или тысяч дробных чисел (например, 2048 измерений для модели Voyage AI voyage-4-large). Прямое сравнение каждого вектора с каждым (brute force) даёт идеальную точность, но при миллионе записей и размерности 2048 потребуется выполнить два миллиарда операций на каждый запрос - это неприемлемо медленно.

Для решения этой задачи были разработаны специальные индексы, которые делают приближённый поиск ближайших соседей (Approximate Nearest Neighbor, ANN) за логарифмическое время. Именно вокруг этих индексов и строятся векторные базы данных.

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

IVFFlat (Inverted File with Flat vectors). Алгоритм разбивает всё пространство векторов на кластеры с помощью кластеризации k-means. При поиске система сначала определяет ближайшие кластеры к запросу, а затем ищет внутри них. Параметр nprobe контролирует, сколько кластеров проверяется: больше кластеров - точнее результат, но медленнее поиск. Главное преимущество IVFFlat - быстрое построение индекса. Это хороший выбор, когда данные часто обновляются и индекс нужно пересоздавать. Недостаток - при малом nprobe можно пропустить релевантные результаты, находящиеся на границе кластеров.

HNSW (Hierarchical Navigable Small World). Более современный и точный алгоритм. Представьте многоуровневую сеть связей между векторами: на верхних уровнях - грубые связи между далёкими точками для быстрой навигации, на нижних - точные связи между близкими точками. Поиск начинается с верхнего уровня и постепенно спускается к нижнему, уточняя результат. Параметр m определяет количество связей (больше связей - точнее, но больше памяти), а ef_construction контролирует качество построения графа. HNSW даёт лучшую точность при сопоставимой скорости, но индекс строится дольше и занимает больше оперативной памяти.

Для большинства бизнес-задач рекомендуется HNSW: его точность выше, а дополнительные затраты на память приемлемы при размерах баз до десятков миллионов записей.

pgvector - это расширение для PostgreSQL, добавляющее тип данных vector и индексы для приближённого поиска ближайших соседей. По сути, pgvector превращает привычный PostgreSQL в векторную базу данных, не требуя отдельной инфраструктуры.

Ключевые возможности pgvector:

• Тип данных vector - хранение векторов любой размерности (до 16 000 измерений). Создание таблицы выглядит привычно: CREATE TABLE items (id serial PRIMARY KEY, embedding vector(2048), content text)
• Индекс IVFFlat - быстрое построение, хорошая скорость поиска для баз до нескольких миллионов записей
• Индекс HNSW - более высокая точность, поддерживается с версии 0.5.0. Это рекомендуемый выбор для большинства задач
• Метрики расстояния - косинусное расстояние (cosine distance), евклидово расстояние (L2), скалярное произведение (inner product). Для текстовых эмбеддингов обычно используют косинусное расстояние
• SQL-совместимость - поиск по векторам комбинируется с обычными SQL-запросами: фильтрация, JOIN с другими таблицами, агрегация

Пример запроса на pgvector: SELECT content, embedding <=> query_vector AS distance FROM items ORDER BY embedding <=> query_vector LIMIT 10. Оператор <=> вычисляет косинусное расстояние, а PostgreSQL использует HNSW-индекс для ускорения.

Преимущества pgvector:

• Единая база данных. Не нужно разворачивать отдельный сервис. Эмбеддинги хранятся рядом с бизнес-данными - пользователями, товарами, документами. Это упрощает JOIN-ы и транзакции
• Знакомый стек. Если команда уже работает с PostgreSQL, pgvector не требует изучения новых инструментов. Тот же SQL, те же инструменты мониторинга, те же бэкапы
• Self-hosted. Полный контроль над данными. Для компаний с требованиями по локализации данных это единственный приемлемый вариант в категории зрелых решений
• Экосистема PostgreSQL. pgBackRest для бэкапов, pgBouncer для пулинга соединений, встроенная репликация для отказоустойчивости. Всё это работает с pgvector без дополнительных настроек
• Стоимость. Расширение бесплатное и с открытым исходным кодом. Платите только за инфраструктуру (серверы, облачные инстансы)

Ограничения pgvector:

• Масштабирование. PostgreSQL масштабируется вертикально - увеличением ресурсов одного сервера. Горизонтальное шардирование возможно (Citus, Neon), но добавляет сложность. Для баз свыше 50-100 миллионов векторов стоит рассмотреть специализированные решения
• Память. HNSW-индекс целиком загружается в оперативную память. Для 10 миллионов векторов размерностью 2048 (float32) индекс займёт около 80-100 ГБ RAM - это серьёзные требования к серверу
• Нет встроенного гибридного поиска. Для комбинации семантического и полнотекстового поиска нужно вручную объединять результаты pgvector и pg_trgm / tsvector

Turbopuffer - облачная векторная база данных, спроектированная для максимальной скорости поиска и простоты использования. В отличие от pgvector, Turbopuffer - это полностью управляемый сервис: вам не нужно думать о серверах, индексах и масштабировании.

Ключевые особенности Turbopuffer:

• Гибридный поиск из коробки. Turbopuffer нативно поддерживает комбинацию семантического (векторного) и полнотекстового (BM25) поиска. Это позволяет одним запросом найти документы, релевантные и по смыслу, и по ключевым словам - что критически важно для продакшен-систем, где пользователи могут искать и по номеру документа, и по описанию проблемы
• Фильтрация по атрибутам. Помимо векторов, можно хранить метаданные (категория, дата, автор) и фильтровать результаты поиска по ним. Фильтрация интегрирована в процесс поиска, а не выполняется постфактум, что обеспечивает стабильную производительность
• Автоматическое масштабирование. Turbopuffer сам распределяет данные по узлам и балансирует нагрузку. Для пользователя база на 100 тысяч и на 100 миллионов записей выглядит одинаково
• Простой REST API. Интеграция сводится к HTTP-запросам: загрузить документы, выполнить поиск, получить результаты. Клиентские библиотеки доступны для Python, TypeScript и других языков
• Оплата по использованию. Нет фиксированной платы за сервер - платите за хранимые данные и выполненные запросы. Это удобно для стартапов и проектов с непредсказуемой нагрузкой

Когда Turbopuffer - лучший выбор:

• Нужен гибридный поиск (семантика + ключевые слова) без ручной интеграции
• Нет ресурсов на администрирование инфраструктуры
• Нагрузка непредсказуемая или растёт быстро
• Данные не содержат государственной тайны и могут храниться в облаке

Ограничения Turbopuffer:

• Облачная привязка. Данные хранятся на серверах Turbopuffer. Для компаний с жёсткими требованиями к локализации данных это неприемлемо
• Vendor lock-in. Миграция с Turbopuffer на другое решение потребует переписывания интеграции и переноса данных
• Стоимость при большом объёме. При постоянной высокой нагрузке (миллионы запросов в сутки) облачная модель оплаты может оказаться дороже, чем собственная инфраструктура

Pinecone - одна из первых коммерческих управляемых векторных баз данных. Pinecone предлагает полностью serverless-архитектуру: вы создаёте индекс, загружаете векторы и выполняете запросы через API.

Сильные стороны Pinecone: стабильная работа под нагрузкой, предсказуемые задержки, широкая экосистема интеграций (LangChain, LlamaIndex, многие фреймворки поддерживают Pinecone из коробки). Pinecone поддерживает фильтрацию по метаданным и namespace-ы для разделения данных между проектами или клиентами.

Основные критические замечания касаются стоимости: при масштабировании до десятков миллионов записей цена растёт значительно. Также Pinecone не поддерживает самостоятельное развёртывание - только облачный сервис. Для российских компаний дополнительным ограничением является то, что серверы расположены за пределами России, а оплата производится в иностранной валюте.

Qdrant - open-source векторная база данных, написанная на Rust. Qdrant изначально проектировался для работы с эмбеддингами и предлагает богатый набор возможностей.

Отличительные особенности Qdrant:

• Гибкая фильтрация. Поддержка сложных условий фильтрации (AND, OR, NOT) с высокой производительностью. Фильтры учитываются при построении маршрута в HNSW-графе, а не применяются постфактум
• Мультивекторный поиск. Один объект может содержать несколько векторов - например, один для текста и один для изображения. Поиск выполняется по любому из них или по комбинации
• Квантизация. Встроенная поддержка scalar quantization и product quantization для уменьшения потребления памяти в 4-8 раз с минимальной потерей качества
• Распределённая архитектура. Горизонтальное масштабирование с шардированием и репликацией для отказоустойчивости

Qdrant можно развернуть на собственных серверах (Docker, Kubernetes) или использовать Qdrant Cloud - управляемый сервис. Открытый исходный код снижает риск vendor lock-in. Из ограничений - Qdrant написан на Rust и требует специфических знаний для тонкой настройки и отладки в продакшене.

Weaviate - open-source векторная база с акцентом на мультимодальность. Weaviate из коробки интегрируется с моделями эмбеддингов: можно загружать текст или изображения напрямую, а Weaviate сам вызовет модель для создания эмбеддинга. Поддерживает гибридный поиск (BM25 + вектор), графовые связи между объектами и модулярную архитектуру. Weaviate хорошо подходит для прототипирования и проектов, где важна скорость разработки. Ограничение - сравнительно высокое потребление ресурсов и сложная конфигурация при масштабировании.

Milvus - open-source проект, изначально созданный в Zilliz. Milvus спроектирован для масштабирования до миллиардов записей с помощью распределённой архитектуры на базе Kubernetes. Поддерживает множество типов индексов (IVF, HNSW, DiskANN, GPU-индексы), различные метрики расстояния и гибридный поиск. Milvus - выбор для крупных корпоративных инсталляций, где объёмы данных измеряются миллиардами записей. Для малого и среднего бизнеса Milvus может оказаться избыточно сложным: кластерная архитектура требует etcd, MinIO, Pulsar и Kubernetes.

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

Скорость поиска (latency). Критична для пользовательских сценариев: если человек ждёт ответа от AI-чата на сайте, допустимая задержка - 100-200 мс на поиск. Для пакетной обработки (классификация тикетов ночью) задержка менее важна. pgvector на сервере с достаточной памятью показывает 5-20 мс для базы в 1-2 миллиона записей. Turbopuffer, Pinecone и Qdrant обычно укладываются в 10-50 мс. Для подавляющего большинства бизнес-задач все рассматриваемые решения обеспечивают достаточную скорость.

Стоимость. Самый значимый фактор для длительной эксплуатации. pgvector - бесплатное расширение, но вы платите за серверы (или управляемый PostgreSQL в облаке). При 5 миллионах записей и размерности 2048 потребуется сервер с 64-128 ГБ RAM - это около 30 000-60 000 рублей в месяц в Яндекс Облаке. Облачные решения (Turbopuffer, Pinecone) на таком объёме могут стоить от 50 до 200 долларов в месяц. При небольших объёмах (до 1 миллиона записей) облачные решения часто дешевле, потому что pgvector всё равно требует выделенного сервера.

Модель хостинга. Self-hosted (pgvector, Qdrant, Milvus, Weaviate) vs управляемый облачный сервис (Turbopuffer, Pinecone, Qdrant Cloud). Self-hosted даёт контроль над данными и предсказуемую стоимость. Облачный сервис снимает бремя администрирования, но создаёт зависимость от провайдера.

Фильтрация и метаданные. Все рассмотренные решения поддерживают фильтрацию по атрибутам. Однако производительность фильтрации сильно различается. Некоторые решения (Qdrant, Turbopuffer) интегрируют фильтрацию в процесс поиска (pre-filtering), что сохраняет скорость. Другие применяют фильтры после поиска (post-filtering), что может привести к недостаточному количеству результатов при строгих фильтрах.

Гибридный поиск. Комбинация векторного (семантического) и полнотекстового (BM25) поиска значительно повышает качество для продакшен-систем. Turbopuffer и Weaviate поддерживают гибридный поиск нативно. Для pgvector нужно вручную комбинировать результаты pgvector и tsvector. Qdrant реализует гибридный поиск через sparse vectors.

Масштабирование. Для баз до 5 миллионов записей любое решение справится на одном сервере. От 5 до 50 миллионов - pgvector справляется на мощном сервере, но стоит рассмотреть Qdrant или Turbopuffer. Свыше 100 миллионов - нужна распределённая архитектура (Milvus, Qdrant с шардированием, Turbopuffer).

Один из самых частых вопросов при планировании инфраструктуры - сколько ресурсов потребуется для хранения и поиска по определённому количеству векторов. Приведём практические расчёты для наиболее распространённой конфигурации: размерность 2048 (Voyage AI voyage-4-large), тип float32.

Размер одного вектора: 2048 измерений x 4 байта (float32) = 8192 байта (8 КБ). С учётом метаданных и индексного оверхеда - примерно 12-16 КБ на запись.

• 100 000 записей - около 1,2-1,6 ГБ. Хватит сервера с 8 ГБ RAM. Подходит для базы знаний средней компании или каталога товаров
• 1 000 000 записей - около 12-16 ГБ. Потребуется сервер с 32 ГБ RAM. Типичный объём для крупного интернет-магазина или службы поддержки
• 10 000 000 записей - около 120-160 ГБ. Нужен сервер с 256 ГБ RAM или переход на облачное решение. Корпоративные архивы, миллионы документов
• 100 000 000 записей - более 1 ТБ. Распределённая система обязательна. Qdrant с шардированием, Milvus или Turbopuffer

Важный нюанс: если используется квантизация (scalar quantization сжимает float32 в int8), потребление памяти сокращается в 4 раза с потерей качества всего 1-3%. Это часто оправданный компромисс для больших баз.

pgvector - оптимальный выбор в следующих ситуациях:

• Вы уже используете PostgreSQL. Не нужно добавлять новый компонент в инфраструктуру. Установка расширения - одна команда: CREATE EXTENSION vector. Все существующие инструменты мониторинга, бэкапа и обслуживания продолжают работать
• Нужны JOIN-ы с бизнес-данными. Эмбеддинги документов хранятся в той же базе, что и информация о пользователях, компаниях, заказах. Можно одним запросом найти семантически близкие документы и отфильтровать их по правам доступа текущего пользователя
• Требования по локализации данных. Все данные остаются на ваших серверах или в управляемом PostgreSQL (например, в Яндекс Облаке). Никакие векторы не передаются третьим сторонам
• Объём данных до 5-10 миллионов записей. На сервере с достаточной памятью pgvector обеспечивает скорость, сопоставимую со специализированными решениями
• Бюджет ограничен. Расширение бесплатное. Для проекта с сотней тысяч записей достаточно минимального сервера
• Транзакционная целостность. pgvector работает внутри транзакций PostgreSQL. Если нужно атомарно обновить документ и его эмбеддинг - это стандартная транзакция BEGIN/COMMIT

Облачная векторная база данных (Turbopuffer, Pinecone, Qdrant Cloud) лучше подходит, когда:

• Нет команды для администрирования. Управляемый сервис берёт на себя обновления, бэкапы, мониторинг и масштабирование. Для стартапа из 3-5 человек это критично - каждый час разработчика ценен
• Нужен гибридный поиск. Turbopuffer предоставляет семантический + полнотекстовый поиск одним API-вызовом. Реализация аналогичной функциональности на pgvector потребует значительно больше усилий
• Нагрузка непредсказуема или быстро растёт. Облачные решения автоматически масштабируются. Если завтра количество запросов вырастет в 10 раз, сервис справится без вашего участия
• Объём превышает 10 миллионов записей. Специализированные решения эффективнее обрабатывают большие объёмы благодаря распределённой архитектуре
• Нужна скорость запуска. Регистрация и первый запрос - за минуты. Не нужно настраивать сервер, устанавливать расширения, конфигурировать индексы

Если вы выбрали pgvector, правильная настройка HNSW-индекса критически влияет на производительность. Основные параметры:

m (количество связей). Определяет, сколько связей создаётся для каждого узла в графе. Значение по умолчанию - 16. Увеличение до 32 или 64 повышает точность поиска (recall), но увеличивает размер индекса в памяти и время построения. Для большинства задач m=16 или m=32 достаточно.

ef_construction (качество построения). Контролирует, насколько тщательно строится граф. Больше значение - качественнее граф, но дольше построение. Значение по умолчанию - 64. Для продакшена рекомендуется 128-256. Этот параметр не влияет на скорость поиска, только на время первичного построения индекса.

ef_search (ширина поиска). Устанавливается через SET hnsw.ef_search = 100. Определяет, сколько кандидатов рассматривается при поиске. Чем больше - тем точнее, но медленнее. Значение по умолчанию - 40. Для продакшена обычно 100-200 обеспечивает recall выше 95%.

Практическая рекомендация: начните с параметров по умолчанию, измерьте recall на тестовом наборе данных (сравните результаты HNSW с результатами brute force), а затем корректируйте ef_search до достижения желаемого баланса скорости и точности.

В Промолитике мы используем оба подхода - pgvector и Turbopuffer - для разных типов задач.

pgvector для базы знаний продуктов и PLG-сценариев. Наш основной продукт использует PostgreSQL как основную базу данных. Когда потребовался семантический поиск по базе знаний для AI-консультанта, логичным выбором стал pgvector. Эмбеддинги (Voyage AI voyage-4-large, 2048 измерений) хранятся в той же базе, что и информация о клиентах, компаниях и настройках ботов. Поиск выполняется с использованием косинусного расстояния через HNSW-индекс, результаты фильтруются по ID компании в одном SQL-запросе. Объём базы - десятки тысяч записей, скорость поиска - менее 10 мс. Для этого сценария pgvector идеален: минимум инфраструктуры, транзакционная целостность, JOIN-ы с бизнес-данными.

Turbopuffer для email RAG. Для проекта поиска по email-архивам мы выбрали Turbopuffer. Архив содержит сотни тысяч писем, объём постоянно растёт. Гибридный поиск Turbopuffer здесь критически важен: когда пользователь ищет по номеру договора - срабатывает полнотекстовый компонент; когда описывает ситуацию своими словами - семантический. Turbopuffer также упростил разработку: мы сосредоточились на пайплайне обработки писем, а не на настройке инфраструктуры хранения. Модель оплаты по использованию идеально подходит для этого проекта с неравномерной нагрузкой.

Наша рекомендация клиентам: если у вас уже есть PostgreSQL и объём данных до нескольких миллионов записей - начинайте с pgvector. Это самый быстрый путь к работающему решению. Если нужен гибридный поиск или объёмы большие - рассмотрите Turbopuffer или Qdrant. Начинать с Milvus имеет смысл только при объёмах от сотен миллионов записей.

Выбор векторной базы - не навсегда. Бизнес растёт, объёмы данных увеличиваются, требования меняются. Хорошая новость: миграция между векторными базами значительно проще, чем кажется.

Основной объём работы - это перенос эмбеддингов и метаданных. Эмбеддинги - просто массивы чисел, они не привязаны к конкретной платформе. Если вы создаёте эмбеддинги с помощью Voyage AI или любой другой модели, они одинаково работают в pgvector, Turbopuffer, Qdrant или любом другом решении.

Типичный сценарий миграции:

• Этап 1. Экспорт данных из текущей базы: эмбеддинги, метаданные, оригинальный текст
• Этап 2. Импорт в новую базу пакетами (batch upsert). Большинство решений поддерживают загрузку тысяч записей за один вызов API
• Этап 3. Обновление кода поиска: замена клиентской библиотеки и формата запросов. Обычно это десятки строк кода
• Этап 4. Параллельная работа обеих баз для тестирования: новая система должна давать результаты, сопоставимые со старой

Мы рекомендуем выносить слой работы с векторной базой в отдельный модуль с чётким интерфейсом (функции upsert, search, delete). Это позволит заменить реализацию без переписывания всей системы.

Выбор векторной базы данных - это инфраструктурное решение, которое влияет на стоимость, производительность и сложность поддержки вашего AI-решения. Нет единственного «лучшего» варианта - есть наиболее подходящий для конкретной ситуации.

pgvector - если у вас PostgreSQL, объём до миллионов записей и нужен контроль над данными. Turbopuffer - если нужен гибридный поиск и управляемый сервис без администрирования. Qdrant - если нужен open-source с расширенными возможностями и горизонтальным масштабированием. Pinecone - если важна экосистема интеграций и стабильная работа под нагрузкой. Milvus - для корпоративных инсталляций с миллиардами записей.

В Промолитике мы помогаем клиентам выбрать оптимальную архитектуру хранения для их конкретных задач и объёмов данных. Если вы планируете внедрение семантического поиска, RAG или AI-ассистента - свяжитесь с нами для бесплатной консультации по выбору инфраструктуры.