Архитектура данных для эпохи агентов: опыт Supabase и эволюция открытой инфраструктуры

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

Тексты и пользователи лежат в реляционной базе, векторы — в облачном сервисе. Теперь тебе нужно вручную синхронизировать удаления, думать об атомарности транзакций и заново изобретать права доступа. Стоит пользователю удалить документ, а фоновому процессу упасть по таймауту — и агент продолжает цитировать удаленные приватные данные из векторного индекса.

Опыт команды Supabase (сооснователи Ант Уилсон и Пол Копплстоун) показал совершенно другой путь: превратить стандартный PostgreSQL в полноценную платформу для ИИ за счет расширения pgvector. Давай разберем, как устроена эта архитектура и как правильно настроить векторный поиск с защитой данных на уровне строк.

Один источник правды: почему реляционная база бьет специализированные хранилища

Ключевой выигрыш от использования PostgreSQL с pgvector — транзакционная целостность (ACID). Векторный эмбеддинг хранится в обычной колонке той же таблицы, где лежат название, дата создания и внешний ключ пользователя:

• Никакой рассинхронизации: если строка удалена в транзакции, удален и вектор.
• Богатые составные фильтры: ты можешь в одном SQL-запросе совместить поиск по смысловой близости векторов с фильтрацией по дате, статусу и тегам.
• Встроенная безопасность ядра PostgreSQL: политики Row Level Security (RLS) фильтруют доступные агенту строки на уровне СУБД, исключая утечку чужих документов.

Ранее мы уже исследовали, как векторные базы данных и масштабирование RAG требуют баланса между скоростью индексации и накладными расходами, а также прослеживали эволюцию RAG от простых векторов к гибридным схемам поиска. Интеграция с PostgreSQL убирает лишний инфраструктурный слой.

Подключение расширения и миграция схемы

Чтобы развернуть векторное хранилище, достаточно выполнить стандартную SQL-миграцию. Создаем расширение, таблицу документов с векторной колонкой размерности 1536 (типичный размер эмбеддингов OpenAI и Gemini) и настраиваем политику RLS:

-- Включаем расширение pgvector
CREATE EXTENSION IF NOT EXISTS vector;

-- Создаем таблицу документов с векторным полем
CREATE TABLE documents (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
  title TEXT NOT NULL,
  content TEXT NOT NULL,
  embedding vector(1536),
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Включаем Row Level Security
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Пользователь видит только свои записи
CREATE POLICY "Users can access own documents"
ON documents FOR ALL
TO authenticated
USING (auth.uid() = user_id);

Графовые индексы HNSW и оптимизация памяти

Если старый тип индекса IVFFlat требовал предварительного обучения кластеров и терял точность при добавлении новых записей, то сегодня стандартом стал HNSW (Hierarchical Navigable Small World). Он строит многослойный граф прямо при вставке данных и обеспечивает быстрый приближенный поиск ближайших соседей (ANN).

Создаем HNSW-индекс по оператору косинусного расстояния (<=>) и выполняем семантический поиск:

-- Строим графовый индекс HNSW
CREATE INDEX documents_embedding_hnsw_idx
ON documents
USING hnsw (embedding vector_cosine_ops);

-- Баланс между точностью и скоростью поиска (по умолчанию 40)
SET hnsw.ef_search = 64;

-- Ищем 5 наиболее близких по смыслу документов
SELECT
  id,
  title,
  content,
  1 - (embedding <=> '[0.012, -0.023, 0.045, ...]'::vector) AS similarity
FROM documents
ORDER BY embedding <=> '[0.012, -0.023, 0.045, ...]'::vector
LIMIT 5;

Практический итог

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