До миллиона эмбеддингов не уходите из Postgres

Minimalist isometric illustration: on the left a large Swiss-army-knife shape labeled "Postgres" with a small "vector" tool extending out, on the right a smaller dedicated short-sword shape labeled "vector DB" glowing softly. A delicate balance scale in the middle. Calm slate-to-indigo palette, no logos, no readable text, clean line work, 16:9, 1600x900.

Каждый месяц кто-то говорит, что Postgres «не справится» с эмбеддингами и пора срочно переезжать.

В большинстве случаев — справляется. Просто не модно.

Простой критерий

До миллиона эмбеддингов — Postgres + pgvector. После — есть разговор. Не «надо переезжать», а «стоит подумать».

На пяти миллионах pgvector часто всё ещё держится — если у вас приличные индексы и нормальный сервер. Я видел продакшены на 12 миллионах, где никто никуда не съезжал.

Что pgvector делает хорошо

• Одна база на всё. Транзакции на documents и chunks вместе с векторами. Никаких танцев с консистентностью через два хранилища.
• JOIN с метаданными. «Найди ближайшие чанки в документах, подписанных в марте, с суммой больше миллиона» — одна SQL-строка.
• Бэкап, репликация, права. Всё, что уже выстроено для Postgres, работает и для векторов. Никаких новых runbook'ов.
• HNSW-индекс с pgvector 0.5+ закрывает большинство практических нагрузок.

Где pgvector реально проседает

Фильтрация при поиске. «Top-10 ближайших среди чанков с пометкой X», 10 миллионов чанков — здесь HNSW плохо дружит с pre-filter. Qdrant с payload-фильтрами выигрывает кратно. Это не миф, это архитектурное.

Hot-data sharding. Qdrant умеет шардировать коллекции и держать горячие в памяти. В Postgres это будет ручная разбивка и собственная боль.

Гибридный поиск. BM25 + векторы можно собрать в Postgres (tsvector + pgvector), но это работа. Qdrant из коробки даёт sparse + dense.

Сигнал к переезду

Не «у нас миллион векторов в базе», а:

«p95 поискового запроса с фильтром по метаданным превысил 200 мс, и оптимизация индексов не помогает».

До этого момента — pgvector. После — Qdrant / Milvus / Weaviate.

И даже тогда лучше держать source-of-truth в Postgres, а в векторной БД — производные данные, которые при беде восстанавливаются переиндексацией. Иначе вы получите два независимых источника правды — это уже не архитектура, это будущий пост-мортем.