Расширения: pgvector, PostGIS, pg_stat

Зачем хранить эмбеддинги в Pinecone, геоданные в MongoDB, логи в InfluxDB и основные данные в PostgreSQL - если всё это умеет PostgreSQL с расширениями? pgvector, PostGIS, TimescaleDB превращают одну БД в платформу, сохраняя единые транзакции, права и SQL.

• **Supabase:** pgvector как основа для semantic search и RAG-приложений - эмбеддинги хранятся рядом с данными, JOINы и RLS работают нативно без синхронизации с отдельной векторной БД
• **Uber:** PostGIS для расчёта зон surge pricing и поиска ближайших водителей; пространственные запросы к 5+ млн активных устройств за миллисекунды через GiST-индексы
• **Grafana Cloud:** TimescaleDB для 10+ млрд метрик в день; continuous aggregates позволяют рендерить годовые графики за < 100 мс без пересчёта миллиардов точек в runtime

Система расширений PostgreSQL

Расширения (extensions) - официальный механизм добавления новых типов данных, функций, индексных методов и операторов в PostgreSQL без модификации ядра. Всё устанавливается одной командой `CREATE EXTENSION` и полностью интегрируется с SQL-синтаксисом, транзакциями и правами доступа.

Расширение устанавливается в конкретную схему (по умолчанию `public`). На managed PostgreSQL (AWS RDS, Google Cloud SQL, Supabase) доступен ограниченный список расширений - не все open-source расширения разрешены провайдером. Проверь список поддерживаемых расширений в документации провайдера.

pgvector: векторный поиск для AI-приложений

pgvector добавляет тип `vector` для хранения эмбеддингов (числовых представлений семантики текста, изображений, аудио) и операторы для поиска ближайших соседей (ANN). Вместо отдельной векторной БД (Pinecone, Weaviate) - всё в PostgreSQL вместе с метаданными.

Supabase использует pgvector для semantic search и RAG-приложений: эмбеддинги хранятся рядом с данными в PostgreSQL, JOIN с user_id, project_id и RLS работают нативно. Это исключает проблему синхронизации данных между PostgreSQL и отдельной векторной БД.

PostGIS: геопространственные данные

PostGIS - крупнейшее расширение PostgreSQL: добавляет типы geometry и geography, 1000+ геофункций, поддержку WKT/WKB/GeoJSON, пространственные индексы GiST/SP-GiST. Используется везде где нужны расстояния, полигоны, маршруты и гео-фильтры.

Uber использует PostGIS для расчёта surge pricing зон и маршрутизации. При 5+ млн активных поездок в день пространственные запросы выполняются за миллисекунды благодаря GiST-индексам. PostGIS превращает PostgreSQL в полноценную GIS-систему без дополнительного ПО.

pg_trgm: нечёткий поиск и опечатки

pg_trgm разбивает строки на триграммы (тройки символов) и на основе их перекрытия вычисляет similarity. Это позволяет находить строки с опечатками, частичным совпадением и без учёта регистра. GIN/GiST-индексы по триграммам дают быстрый поиск по `LIKE '%text%'`.

GIN-индекс по pg_trgm делает `WHERE column LIKE '%text%'` быстрым - это один из главных use cases. Обычный B-tree индекс не помогает при LIKE с ведущим `%`. На таблице с 10+ млн строк это разница между 5 секундами и 5 миллисекундами.

pg_cron: планировщик задач внутри PostgreSQL

pg_cron - расширение-планировщик: выполняет SQL-запросы и функции по расписанию cron прямо внутри PostgreSQL. Не нужен внешний cron-демон, не нужно соединение с БД из внешнего скрипта - задача живёт вместе с данными.

pg_cron работает только с базой postgres (shared_preload_libraries). Задачи можно запускать в другой базе через `cron.schedule_in_database()`. Важно: при падении PostgreSQL незавершённые задачи не перезапускаются автоматически - проверяй `cron.job_run_details` для мониторинга.

TimescaleDB: time-series поверх PostgreSQL

TimescaleDB - расширение, превращающее PostgreSQL в специализированную time-series БД. Ключевые концепции: hypertable (автоматически партиционируется по времени), continuous aggregates (автоматически обновляемые материализованные представления), политики retention и compression.

Grafana использует TimescaleDB для хранения метрик Grafana Cloud: 10+ млрд точек в день. Continuous aggregates позволяют отображать графики за год за миллисекунды - без них каждый запрос пересчитывал бы миллиарды строк. Compression снижает объём хранения в 10-20 раз.

Итоги

• **pgvector:** хранение и поиск эмбеддингов прямо в PostgreSQL; HNSW-индекс для ANN-поиска; cosine `<=>`, L2 `<->`, inner product `<#>` операторы
• **PostGIS + pg_trgm:** гео-данные (geography для глобальных расстояний, GiST-индекс) и нечёткий поиск (GIN-индекс делает `LIKE '%text%'` быстрым)
• **pg_cron + TimescaleDB:** автоматизация задач по расписанию без внешних сервисов; time-series с автоматическим партиционированием, compression и continuous aggregates

Связанные темы

Расширения усиливают другие механизмы PostgreSQL:

• Полнотекстовый поиск — pg_trgm дополняет встроенный FTS: там где tsvector не справляется с опечатками, триграммный поиск находит похожие строки
• Партиционирование таблиц — TimescaleDB автоматизирует управление партициями для time-series; pg_cron автоматизирует создание партиций для стандартного партиционирования
• JSONB и GIN-индексы — pgvector добавляет новый тип данных и индексные методы (HNSW, IVFFlat) - аналогично тому как JSONB расширяет PostgreSQL через GIN

Вопросы для размышления

• Приложение хранит пользовательские эмбеддинги в Pinecone и основные данные в PostgreSQL. Какие проблемы возникают при такой архитектуре? Когда pgvector является лучшим решением?
• Таблица `products` содержит 50 млн записей. Запрос `WHERE name ILIKE '%samsung%'` занимает 8 секунд. Как ускорить без изменения SQL-запроса?
• TimescaleDB compression экономит 90% места, но делает данные read-only для INSERT/UPDATE. Для каких данных это приемлемо, а для каких - нет?

Связанные уроки

• db-10-indexes-advanced