Платформа/journal
Postgres + pgvector на масштабе
Postgres + pgvector на масштабе: архитектура для миллионов векторов
← ЖурналПлатформа7 мин чтения

Postgres + pgvector на масштабе: архитектура для миллионов векторов

Команда nordiqdev
студия

Когда строишь RAG, первый вопрос инфраструктуры - где хранить векторы. Стартапы рекомендуют Pinecone. Хайп - за Qdrant и Weaviate. Мы на двух из последних трёх проектов остались на Postgres с pgvector. Расскажем, почему и как это масштабируется.

Почему Postgres

  • Уже есть в проекте - не нужно вводить новую систему хранения и репликации.
  • ACID-транзакции с обычными данными: вектор и метаданные обновляются атомарно.
  • Сложные фильтры по метаданным с использованием обычного SQL и индексов.
  • Один backup, один процесс восстановления, одна point-in-time recovery.
  • Стоимость ниже на средних объёмах, особенно если уже платите за БД.

Когда специализированная vector-БД лучше

  • Очень большие объёмы (100М+ векторов) - pgvector упирается в память на одну ноду.
  • Очень высокий QPS на векторный поиск (>10k QPS) - специализированные движки оптимизированы под это.
  • Нужен sharding по векторам - в Postgres это нетривиально.
  • Команда уже выбрала «vector-first» архитектуру и не хочет нагружать основную БД.

Индексы: HNSW vs IVFFlat

В pgvector два индекса. IVFFlat - построение быстрее, поиск медленнее, требует тюнинга lists. HNSW - построение медленнее (можно загрузить ноду на часы при первом построении), поиск быстрее и качественнее. На проектах от 100k векторов мы по умолчанию ставим HNSW.

Параметры HNSW: m=16, ef_construction=64 - хороший дефолт. Если recall важнее (медицина, юр) - поднимать m до 32 и ef_search до 100. Каждое удвоение даёт 1–3 процентных пункта recall и 30–50% дополнительного времени поиска.

Фильтрация по метаданным

Главная сила Postgres - комбинировать векторный поиск с обычными WHERE. Но порядок выполнения важен: WHERE сначала, потом векторный поиск среди отфильтрованных кандидатов - намного быстрее, если фильтр сильно сужает выборку. Для этого надо использовать составные индексы и явно подсказывать планировщику.

Партиционирование

Если данные естественным образом делятся на партиции (по тенантам, по периодам) - партиционирование радикально упрощает масштабирование. Каждая партиция - свой HNSW-индекс, удаление старых данных = drop партиции, без vacuum-боли.

Сколько мы держим

На самом большом из наших pgvector-проектов: 14 миллионов векторов размерности 1024, p99 latency векторного поиска ~80 мс с фильтром по тенанту, recall@10 ~94%. Машина - 16 vCPU / 64 ГБ RAM. Стоимость - около $400/мес. Аналогичный объём в Pinecone - кратно дороже.

Теги
#postgres#pgvector#vector search#rag#база данных
Студия nordiqdev

Делаем мобильные приложения, веб-сервисы и AI на заказ

Если задача из текста выглядит знакомой и нужна команда, которая соберёт продукт - расскажите подробнее. Вернёмся в течение 24 часов с разбором.