Векторные базы данных

Короткая версия

Vector DB нужна, если вы хотите сами контролировать:

• хранение embeddings;
• metadata filters;
• hybrid retrieval;
• reranking pipeline;
• tenancy / ACL / namespaces;
• storage economics.

Частые варианты

Запрос: «как настроить уведомления»

Индекс содержит embedding-и help-статей и metadata `product=mobile`, `lang=ru`.

На что смотреть в первую очередь

• filters и metadata support;
• hybrid search / sparse+dense;
• multi-tenancy и ACL;
• storage and scaling profile;
• hosted vs self-hosted operations.

1. Когда vector DB реально нужна

Она нужна не “потому что так делают все”, а когда вы хотите свой retrieval layer:

• сами индексируете документы;
• сами выбираете embeddings;
• сами контролируете filters, top-k, reranking;
• сами храните metadata и access rules.

Если же retrieval уже hosted у провайдера, то отдельная vector DB может быть не нужна вообще.

Практически есть три режима:

1. Hosted retrieval: platform-managed vector stores / file search.
2. Light custom retrieval: local DB или Postgres extension.
3. Full custom retrieval: специализированная vector DB с filters, hybrid и scale controls.

2. Что важнее, чем просто nearest neighbor search

Старые статьи о vector DB часто делают вид, что вся разница только в скорости ANN search. В 2026 это слишком узко.

Для production RAG обычно важнее:

• metadata filtering;
• namespaces / tenancy;
• hybrid search;
• sparse + dense retrieval;
• payload size and indexing cost;
• backup / restore / migration;
• access control boundaries;
• observability of search behavior.

Именно эти вещи часто определяют, выдержит ли retrieval реальный продукт.

3. Qdrant, Chroma, pgvector, Pinecone: practical framing

Chroma

Хорош для:

• local development;
• demos;
• small experimental RAG stacks;
• простых knowledge bases без сложной tenancy.

Плохая идея, если вам уже нужны серьёзные operational guarantees и complex production traffic.

Qdrant

Обычно логичен, когда нужен self-hosted production retrieval:

• filters;
• payload-aware search;
• hybrid queries;
• predictable standalone service;
• нормальный путь к росту объёма данных.

Qdrant часто выбирают не потому, что он “моднее”, а потому что он довольно хорошо балансирует retrieval features и self-hosted practicality.

pgvector

Очень недооценённый выбор, если у вас уже есть Postgres-centric stack.

Хорошо подходит, когда:

• команда уже живёт в PostgreSQL;
• данных умеренно много;
• нужен SQL + metadata joins + transactional simplicity;
• не хочется поднимать ещё один сервис.

Плохая идея, если retrieval уже становится главным системным bottleneck и нужен отдельный search engine profile.

Pinecone

Полезен как managed cloud retrieval path:

• меньше DevOps;
• проще elastic scaling;
• быстрее enterprise/cloud rollout.

Но это уже другой tradeoff: меньше control surface, больше vendor dependency и свои cost curves.

4. Hosted vector stores тоже меняют выбор

OpenAI current docs по file_search показывают важный сдвиг: для многих приложений можно вообще не выбирать самостоятельную vector DB как первый шаг.

То есть у вас теперь есть ещё один путь:

• загрузить файлы;
• дать платформе их индексировать;
• подключить retrieval через file_search или vector_store.

Это особенно полезно, если:

• нужен быстрый запуск;
• corpus не гигантский;
• не хочется самим собирать retrieval infra;
• managed API stack вас устраивает.

Поэтому статья про vector DB в 2026 должна честно говорить: иногда лучшая database choice — это пока никакая, потому что hosted retrieval already good enough.

5. Hybrid search и filters часто важнее raw speed

Production RAG редко живёт на “одном dense similarity”.

Нужны ещё:

• keyword-sensitive queries;
• exact product names and IDs;
• language filters;
• tenant isolation;
• access level filters;
• document type filters.

Именно поэтому выбор storage часто упирается в вопрос:

насколько хорошо база справляется не просто с nearest neighbors, а с retrieval rules моего продукта?

Если у вас много structured metadata, то filters + lexical matching + reranking могут быть важнее, чем ещё 5% скорости dense search.

6. Когда какая база обычно подходит

7. Когда vector DB вообще не нужна

Да, это тоже нормальный ответ.

Она может быть не нужна, если:

• corpus маленький;
• можно использовать hosted retrieval;
• достаточно keyword/full-text search;
• knowledge base обновляется редко и выборка маленькая;
• retrieval layer пока не доказал product value.

Очень частая ошибка — поднять полноценную vector DB раньше, чем команда вообще поняла, нужен ли ей семантический retrieval в проде.

8. Частые ошибки выбора

• выбирать базу “на вырост”, когда данных пока слишком мало;
• недооценивать metadata filtering;
• игнорировать backup/migration story;
• брать отдельный vector DB, хотя hosted retrieval уже покрывает use case;
• брать pgvector, если retrieval уже требует отдельного search profile;
• думать, что base latency важнее product constraints и ACL.

Минимальный pgvector flow

import psycopg2

conn = psycopg2.connect("postgresql://user:pass@localhost/db")
cur = conn.cursor()

cur.execute("CREATE EXTENSION IF NOT EXISTS vector")
cur.execute("""
CREATE TABLE IF NOT EXISTS docs (
    id bigserial PRIMARY KEY,
    tenant_id text,
    lang text,
    content text,
    embedding vector(1536)
)
""")
cur.execute("""
CREATE INDEX IF NOT EXISTS docs_embedding_hnsw
ON docs USING hnsw (embedding vector_cosine_ops)
""")
conn.commit()

Минимальный Qdrant flow

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance

client = QdrantClient(":memory:")

client.create_collection(
    collection_name="docs",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

Важно не то, насколько мало кода у первого примера, а то, что у storage choice всегда есть operational последствия: backup, scaling, tenancy, filters, cost.