В этом материале
pgvector добавляет векторный поиск к PostgreSQL. Оцените индексы и совместную нагрузку до переноса RAG в рабочую базу: размер векторов не описывает все расходы сервера.
PostgreSQL с расширением pgvector позволяет хранить векторы рядом с прикладными данными и выполнять поиск средствами базы. Такой вариант полезно проверить, когда команда уже обслуживает PostgreSQL и хочет связать поиск с существующими записями. Выбор сервера зависит от индекса, объёма корпуса и общей нагрузки базы.
Материал опирается на официальную документацию, проверенную 1 ноября 2026 года. Разворачивать эксперимент прямо на критичной рабочей базе без отдельного плана не требуется.
Определите, что хранится в таблице
pgvector README описывает векторные типы и способы поиска. Зафиксируйте размерность, представление векторов, идентификатор исходного фрагмента и модель эмбеддингов. Изменение модели может потребовать нового представления данных, даже если таблица внешне осталась прежней.
Число исходных документов не равно числу строк после разбиения. Для пилота сохраните фактическое количество фрагментов и размер метаданных. Это позволяет объяснить рост диска без предположения, что вся разница связана только с векторным индексом.
Выберите проверяемый способ поиска
| Подход | Что сравнивать в пилоте |
|---|---|
| Точный поиск | Базовый результат и время на выбранном корпусе |
| HNSW | Качество, память и построение графа |
| IVFFlat | Подготовку индекса и параметры поиска |
Не выбирайте индекс по чужому рейтингу без своего набора запросов. Требования к обновлению и фильтрации могут изменить решение. Базовый точный результат на посильной выборке полезен как контроль качества приближённого метода.
Для приближённого поиска pgvector фильтр применяется после сканирования индекса, поэтому итог может содержать меньше строк, чем запрошенный LIMIT. Это важно для разграничения корпусов RAG. Начиная с версии 0.8.0 документация описывает iterative scans для расширения поиска; настройку и пределы проверяйте на своей версии расширения и собственных фильтрах.
Разделите память обслуживания и запросов
PostgreSQL Resource Consumption объясняет настройки памяти и их область действия. Буферы сервера, память отдельных операций и построение индексов не следует считать одним общим параметром, которому можно отдать всю RAM.
В документации pgvector отдельно описана память построения HNSW. Проверьте её на вашей версии и объёме. Увеличение настройки может изменить поведение одной операции, но не отменяет память других процессов базы и операционной системы.
Измерьте влияние на существующие задачи
Условная команда добавляет поиск по документам к серверу, который уже обслуживает транзакционное приложение. Она сравнивает обычный день, индексирование новой партии и одновременные поисковые обращения. Важно увидеть не только скорость RAG, но и задержки прежних операций.
Сохраните план запросов, размер индекса и фактический ресурсный профиль. Для оценки занятого места можно использовать штатные функции PostgreSQL на своей тестовой таблице. Не принимайте размер одного файла за весь объём хранения, восстановления и сопровождения.
Проверьте жизненный цикл
Добавьте, измените и удалите тестовые документы, затем повторите поиск. Убедитесь, что обновление прикладных данных согласовано с эмбеддингами. Резервная копия должна включать данные и сведения, необходимые для воспроизводимого восстановления поискового поведения.
Далее полезны память векторной базы и локальная RAG-архитектура.