PostgreSQL с pgvector: бюджетное RAG-решение за 1 час в 2026

Что такое pgvector и зачем он живет в PostgreSQL

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

По состоянию на 2026 pgvector уже не выглядит игрушкой для ML-энтузиастов. HNSW-индексы, поддержка cosine/L2/IP, нормальная работа на десятках миллионов векторов, плюс надстройки вроде pgvectorscale от Timescale дают сотни запросов в секунду на обычном железе. Для большинства RAG задач этого за глаза, особенно если мы не строим клон Google.

Как я объясняю pgvector людям без ML-бэкграунда

Когда я обсуждаю PostgreSQL с pgvector с финансовыми директорами или юристами, я никогда не начинаю с «векторных пространств». Я говорю проще: раньше ваша база могла искать только по словам и фильтрам, теперь она умеет искать «по смыслу». Запрос «как оформить декрет» найдет документы, где написано «отпуск по беременности и родам», даже если там нет ни слова «декрет».

Технически это выглядит так: pgvector добавляет колонку типа vector(N) и функцию сравнения <=>, которая считает расстояние между векторами. Вы создаете индекс HNSW, и PostgreSQL внезапно начинает вести себя как векторная база. Я раньше думала, что для такого обязательно нужен отдельный продукт, но после пары нагрузочных тестов в PROMAREN поменяла мнение.

Где pgvector особенно уместен в РФ

В РФ к этому добавляется своя реальность: 152-ФЗ, требования к локализации и не всегда уютные санкционные истории. Когда ваш RAG крутится на PostgreSQL в контуре компании или у локального провайдера, история с согласиями и DPIA дышит гораздо спокойнее, чем при использовании зарубежных managed-векторных сервисов.

Те же Selectel, VK Cloud или отечественные аналоги уже предлагают кластеры PostgreSQL с pgvector "из коробки". Для меня это значит, что я могу за час поднять базу, где рядом лежат JSONB с документами и vector с эмбеддингами, и не придумывать схемы синхронизации. Это особенно ценится в проектах, где внутренний аудит (мой старый дом) смотрит под микроскоп каждое соединение наружу.

Когда pgvector точно не ваш выбор

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

Ещё один кейс - когда команда базы и команда ML сидят в разных мирах и не готовы делить ответственность за один кластер. В таком случае я иногда оставляю pgvector только как прототип для RAG, а дальше разворачиваем отдельное векторное хранилище. Но за последний год у нас в PROMAREN таких случаев было меньше трети - чаще всё заканчивается тем, что PostgreSQL спокойно тащит прод.

Как устроено RAG решение поверх обычной базы

RAG решение - это способ научить модель отвечать не "из головы", а на основе ваших документов, добавляя шаг поиска по векторам перед генерацией. По факту это две операции: сначала достать релевантные куски из базы, потом собрать из них осмысленный ответ через LLM.

В 2026 я почти в каждом проекте вижу одну и ту же цепочку: чанкуем текст, считаем эмбеддинги, кладем в PostgreSQL с pgvector, а дальше играем запросами. Формула кажется простой, пока не начинаешь выбирать размер чанка, модель эмбеддингов и тип расстояния - там и прячется половина "почему наш RAG отвечает ерунду".

Какие шаги в RAG по факту критичны

Я не люблю продавать RAG как магию, поэтому раскладываю его на скучные, но честные шаги. Сначала мы берём документы - от регламентов до инструкций в Confluence - и режем их на фрагменты 500-1500 символов с оверлапом. Затем для каждого фрагмента считаем эмбеддинг через модель уровня text-embedding-3-small или её локальные аналоги.

Дальше начинается роль PostgreSQL: мы создаём таблицу с полями id, content, embedding, metadata и загружаем туда все эти пары "текст-вектор". Индекс HNSW учит базу быстро искать ближайшие векторы к эмбеддингу запроса пользователя. RAG запрос - это по сути: возьми топ-N похожих фрагментов и передай их как контекст в LLM. Вся интеграция AI завязана на том, насколько аккуратно вы держите эту цепочку.

Кейс: как RAG исправил поиск по внутреннему аудиту

В одном из проектов у нас был классический корпоративный портал: конструктор статей, поиск по ключевым словам, недовольные внутренние аудиторы. На запрос "как оформить доступ внешнему подрядчику" система показывала кучу нерелевантных страниц, и сотрудники тратили по 10-15 минут на поиск нужного абзаца.

Мы сделали простой RAG поверх PostgreSQL с pgvector: выгрузили статьи, порезали на чанки, посчитали эмбеддинги через локальную модель и сложили всё в одну таблицу. Через неделю пилота метрика "нашел ответ с первого запроса" выросла с 40% до 80+, а среднее время поиска упало до 2 минут. Забавно, но сложнее всего было не подключить Yandex Neuro или другую LLM, а убедить ИТ, что база выдержит ещё и векторные запросы.

Почему RAG так хорошо стыкуется с PostgreSQL

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

Плюс, RAG редко живёт сам по себе. Ему нужен доступ к правам доступа, статусам, историям изменений - и всё это уже лежит в вашей базе. Именно поэтому сейчас мне проще объяснить архитектору, почему мы делаем ещё один индекс в PostgreSQL, чем убеждать его протащить в контур новую векторную СУБД с отдельной поддержкой и мониторингом. А дальше мы уже незаметно переходим к выбору стека.

Почему я снова выбираю PostgreSQL с pgvector

В 3 из 5 проектов в 2025-2026 я в итоге прихожу к тому, что PostgreSQL с pgvector - это честный компромисс между скоростью, стоимостью и контролем над данными. Не идеальный для всего на свете, но очень устойчивый "рабочий лошадь" для RAG поверх корпоративных документов.

Главная причина - архитектурная честность: в одной транзакции живут и данные, и эмбеддинги, и права доступа, без странных мостиков и двойной синхронизации. Это критично, потому что любая рассинхронизация в RAG бьёт по доверию к ассистенту: он показывает устаревший регламент, а отвечать за это всё равно вам.

Чем PostgreSQL выигрывает у отдельных векторных баз

Я люблю сравнивать подходы табличкой, а не эмоциями. Вот как это обычно выглядит, когда мы с командой садимся выбирать стек RAG в PROMAREN:

Когда нагрузка средняя, а документов не миллиарды, выбор обычно очевиден. Специализированные векторные СУБД выигрывают на экстремальных масштабах и специализации, но проигрывают там, где важна простота и прозрачность для аудита и ИБ. В РФ это чувствуется особенно сильно - одно дело объяснить проверяющим PostgreSQL, другое - новый модный сервис, про который никто не слышал.

Где помогает интеграция с инфраструктурой 2026 года

К 2026 году появились приятные бонусы: многие managed-сервисы уже поддерживают pgvector официально. Selectel, некоторые провайдеры, похожие на Render, и часть локальных облаков дают создать инстанс PostgreSQL с pgvector в пару кликов. Это значит, что для пилотного RAG решения вам не нужен отдельный DevOps - достаточно человека, который умеет нажимать "создать базу" и не боится psql.

По данным Timescale и обзоров рынка от Gartner (Gartner), тренд 2025-2026 как раз такой: компании стараются уменьшать количество сервисов в стеке и переносить лёгкие ML-задачи ближе к данным. PostgreSQL интеграция 2026 с векторными типами в этом смысле попадает точно в цель. Мы в PROMAREN видим, как это экономит 50-70% затрат на инфраструктуру в сравнении со схемой "PostgreSQL + векторная DB + ещё два сервиса вокруг".

Кейс: когда отдельная векторная база всё испортила

Был у меня проект, где команда настояла на отдельной векторной СУБД "потому что модно". Сделали: PostgreSQL для CRM, отдельная база для эмбеддингов, два коннектора, две очереди на синхронизацию. На бумаге красиво, на практике - периодические рассинхронизации, загадочные баги "документ в CRM есть, а в RAG его нет", и отдельный мониторинг ещё одного сервиса.

Через пару месяцев мы честно сели, посчитали время DevOps и ИТ, и переехали на PostgreSQL с pgvector. Объём данных позволял, а экономия по поддержке была такой, что никто особо не спорил. Я, конечно, молча порадовалась, потому что именно это предлагала с самого начала. И плавно мы подошли к самому частому вопросу: а реально ли собрать всё бюджетно и быстро.

Можно ли создать бюджетное RAG решение за 1 час

Да, но только если не обещать за этот час идеальную безопасность, красивую админку и отчёты в Power BI. За 1 час в 2026 реально развернуть рабочий прототип RAG решения на PostgreSQL с pgvector: база, таблица, пара десятков документов, запрос на поиск и простой вызов модели.

Это не маркетинговый "час до продакшена", а честный "час до первого осмысленного ответа от ассистента". В проектах PROMAREN я обычно использую этот формат как экспресс-доказательство того, что концепция вообще годится - а уже потом добавляю роли, логирование, 152-ФЗ и остальные взрослые вещи.

Как я укладываю прототип RAG в один час

Сейчас опишу, как это выглядит в живом сценарии, а не как идеальная презентация. Мы садимся с ноутбуком, у меня уже есть учётка у провайдера, который даёт PostgreSQL, и список 50-100 документов в удобном виде. Кофе успевает остыть, но это уже детали.

• Поднимаем инстанс PostgreSQL у локального провайдера или в контуре компании, сразу с включённым pgvector.
• Создаём таблицу с content, embedding и metadata, добавляем HNSW-индекс по embedding.
• Через простой скрипт или n8n считаем эмбеддинги (иногда через Yandex Neuro) и заливаем всё в базу батчами.
• Пишем один запрос с ORDER BY embedding <=> $embed LIMIT 5 и заворачиваем его в HTTP-слой.
• Подключаем модель (локальную или облачную), скармливаем туда найденный контекст и текст вопроса.

Через 40-50 минут у нас уже есть телеграм-бот или простая веб-форма, которая отвечает по документам лучше, чем штатный поиск. Всё это вполне дружит с автоматизацией через n8n или Make.com, про которые я иногда подробнее пишу в разделе статьи про AI-инструменты и практику с нейросетями. Самое приятное - это всё ещё один инстанс PostgreSQL, без отдельного векторного счёта в валюте.

Где обычно ломается "за 1 час"

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

Второй типичный стопор - права доступа и 152-ФЗ. Когда выясняется, что внутри документов полно персональных данных, приходится сразу думать, кто и что может видеть через RAG. Главное правило: все персональные данные остаются в контуре компании, а доступ к PostgreSQL строго ограничен. В пилотах я иногда просто беру обезличенные документы, чтобы не останавливаться на старте. А потом, когда прототип начинает приносить пользу, мы уже аккуратно подводим его под white-data методику PROMAREN.

Мини-кейс: FAQ-бот, который окупился за квартал

В одном проекте мы сделали FAQ-бота на PostgreSQL с pgvector для службы поддержки. Загружали около тысячи типовых вопросов и ответов, сотню внутренних регламентов и инструкции для операторов. Основная задача была не "заменить людей", а сократить время, которое они тратят на поиск формулировок и сценариев.

Через три месяца метрики показали, что бот снимает до 30% повторяющихся запросов первого уровня, а у операторов среднее время обработки сложных кейсов сократилось на треть. В пересчёте на FTE это выглядело как экономия двух полных ставок, без сокращений, просто за счёт роста пропускной способности команды. И всё это - на одном PostgreSQL, без отдельной векторной фермы в облаке. Дальше логичный вопрос - а какие ещё преимущества даёт pgvector в таком сетапе.

Какие преимущества pgvector для RAG в 2026

Самое заметное преимущество pgvector для RAG - это ощущение, что вы не строите космический корабль ради поиска по документации. В PostgreSQL с pgvector всё складывается в одну понятную историю: знакомая база данных, векторное хранилище внутри и нормальные инструменты для оптимизации запросов.

С точки зрения архитектуры это значит, что DevOps не проклинают вас за ещё один сервис, ИБ понимает, что тут проверять, а команда аналитики может использовать те же данные и для RAG, и для отчётов. В начале 2026 я всё чаще вижу, как компании сначала пробуют RAG на отдельных сервисах, а потом возвращаются к PostgreSQL именно за счет прозрачности.

Что даёт pgvector в повседневной работе

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

В-третьих, возможности по оптимизации запросов: комбинировать векторный поиск с фильтрами по отделу, роли, языку, статусу документа. Всё это обычный SQL, который знают ваши разработчики и аналитики. За счёт этого RAG перестаёт быть "магическим чёрным ящиком" и превращается в обычный сервис, который можно измерять и улучшать. Для меня это лучший комплимент архитектуре.

Типичные ошибки при работе с pgvector и как их не повторить

За 2025-2026 в проектах PROMAREN я насмотрелась на одни и те же грабли. Забытый индекс HNSW, и запросы начинают ползать в 100 раз медленнее, чем могли бы. Неверная размерность векторов: модель выдаёт 1024, а колонка стоит на 1536, или наоборот - и вы ловите ошибки вставки. Отсутствие батчевой загрузки, из-за чего наполнение базы занимает дни вместо часов.

Здесь работает простой здравый смысл: сначала делаем минимальный прототип на десятках документов, проверяем размерность, качество поиска и нагрузку на память, и только потом запускаем массовую заливку. По данным Timescale (Timescale), HNSW индексы стабильно держат миллионы векторов на разумном железе, но RAM нужно считать заранее. Я поняла, что лучше один раз потратить день на нагрузочный тест, чем потом объяснять, почему прод внезапно решил уйти в своп.

Куда движется рынок и как вписаться без боли

Тренды 2025-2026 года довольно прозрачны: крупные игроки вроде Yandex Neuro, Google AI Overview и аналогичные системы показывают, что пользователи ждут "поиска по смыслу" везде, где есть текст. Компании в РФ пытаются повторить это у себя, но с поправкой на 152-ФЗ, бюджет и отсутствие желания плодить инфраструктурный зоопарк.

Мне кажется, что ближайшие пару лет PostgreSQL с pgvector будет тем самым "дефолтным решением для RAG", особенно в корпоративном сегменте. На сайте PROMAREN я уже выделила отдельную зону под подход PROMAREN и методику white-data, чтобы не объяснять каждый раз с нуля, почему мы так упрямо тянем векторное хранилище поближе к данным. А в канале канал PROMAREN продолжаю разбирать кейсы, где this "скромный" стек PostgreSQL + pgvector вытесняет более сложные схемы. Кажется, это надолго.

Что остаётся в сухом остатке

Если убрать хайп, остаётся несколько очень приземлённых наблюдений. Во-первых, RAG на PostgreSQL с pgvector почти всегда дешевле и быстрее старта, чем связка из двух-трёх отдельных сервисов. Во-вторых, такая архитектура лучше переживает проверки ИБ, аудит и реальность 152-ФЗ, потому что понятна и предсказуема.

И в-третьих, чем ближе вы держите векторное хранилище к своим данным, тем проще дальше автоматизировать: отчёты, алерты, аналитику запросов. В этом смысле "бюджетное решение за 1 час" - это не про магию, а про аккуратный выбор стека, который потом не стыдно масштабировать.

Обо мне. Я - Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead, раньше занималась внутренним аудитом и ИТ-рисками. С 2024 года помогаю командам в РФ строить white-data RAG системы и AI-агентов под 152-ФЗ. За 12 месяцев мы запустили десятки решений на PostgreSQL с pgvector, о которых пишу в блоге и разбираю в канале PROMAREN.

Если хочется не просто прочитать статью, а собрать свой прототип RAG на PostgreSQL с pgvector, можно заглянуть на сайт PROMAREN - там я собираю рабочие схемы и разборы. А чтобы посмотреть, как это живёт в боте, проще всего зайти в тестовый доступ и потрогать руками.

Что ещё важно знать

Можно ли обойтись без отдельной векторной базы и жить только на PostgreSQL с pgvector?

Да, для большинства внутренних RAG задач достаточно PostgreSQL с pgvector без отдельной векторной базы. Это подходит, если у вас десятки или сотни миллионов векторов, умеренная нагрузка и нет экстремальных требований к латентности. Такой подход упрощает архитектуру, экономит инфраструктурный бюджет и делает проверки ИБ и аудита более предсказуемыми и спокойными.

А что делать, если нагрузка растет и PostgreSQL перестаёт справляться с RAG?

Если PostgreSQL с pgvector начинает упираться в ресурсы, сначала имеет смысл оптимизировать индексы, запросы и железо. Часто помогает шардирование, перенос части нагрузки на read-реплики и более аккуратное проектирование чанков. Только если после этого база всё равно не тянет, стоит думать о выделенной векторной СУБД для самых тяжёлых сценариев.

Можно ли строить RAG на PostgreSQL в проектах с персональными данными по 152-ФЗ?

Да, PostgreSQL с pgvector можно использовать в проектах с персональными данными, если база развёрнута в контуре, который соответствует 152-ФЗ. Это предполагает ограниченный доступ, аудит действий, резервное копирование и понятные регламенты. Важно следить, чтобы эмбеддинги с ПДн не уходили в внешние сервисы без правовых оснований и корректных согласий.

Как понять, что качество поиска в моём RAG на pgvector уже достаточно хорошее?

Хорошее качество RAG видно по тому, что пользователи начинают доверять ответам и меньше "гуглят параллельно". На практике это 70-85% релевантности по оценкам людей и заметное сокращение времени на поиск ответов. Я советую раз в пару недель собирать выборку запросов, смотреть, какие ответы не устроили сотрудников, и дообучать пайплайн чанкинга и фильтров.

Можно ли использовать разные модели эмбеддингов в одной базе PostgreSQL с pgvector?

Да, можно хранить в PostgreSQL с pgvector эмбеддинги от разных моделей, но лучше разделять их по колонкам или таблицам. Векторы разные по размерности и распределению, поэтому смешивать их в одном поле не стоит. Чаще делают отдельные столбцы или даже схемы под разные источники, а приложение понимает, какую связку "модель + колонка" использовать.