Postgres 19 получил невероятное обновление

Postgres 19 выпускает «бомбу»: нативную поддержку SQL/PGQ (Property Graph Queries). Это не просто обновление, а фундаментальный сдвиг, позволяющий вам опрашивать стандартные реляционные таблицы с помощью интуитивно понятного синтаксиса обхода графов. Забудьте о днях, проведенных в мучениях над цепочками JOIN между множеством таблиц; ваши связи данных получили серьезное обновление удобства использования.

Раскройте эту мощь с помощью CREATE PROPERTY GRAPH, определяя логический слой графа прямо поверх вашей существующей схемы. Вы назначаете таблицы в качестве вершин — основных узлов данных, таких как customers или products, — а таблицы связей в качестве ребер, критических соединений, таких как customer_orders или order_items. Важно отметить, что эта настройка оставляет вашу базовую структуру данных нетронутой; это представление, а не миграция.

Эта элегантная абстракция значительно упрощает запросы, которые ранее требовали длинного, подверженного ошибкам каскада операторов JOIN. Представьте, что вы распутываете всю историю покупок клиента по пяти таблицам; этот сложный SQL-беспорядок теперь превращается в упорядоченный, читаемый обход графа. Для разработчиков это означает более простой в написании, более легкий для чтения и более простой в поддержке код, что напрямую влияет на продуктивность и снижает сложность запросов.

Разработчики долгое время боролись с дилеммой «получить или создать» при взаимодействии с базой данных. До появления Postgres 19 для реализации этого распространенного паттерна требовались два отдельных запроса: попытка INSERT, за которой следовал SELECT, если вставка не удалась из-за конфликта. Этот двухэтапный танец приводил к состоянию гонки (race conditions) и требовал сложной логики на стороне приложения — неуклюжий и подверженный ошибкам процесс.

Теперь, с Postgres 19, правила игры меняются. Новый оператор ON CONFLICT DO SELECT обеспечивает атомарную операцию «получить или создать», о которой мы всегда мечтали. Этот единственный элегантный запрос гарантирует, что вы либо вставите новую строку, либо, если возникнет конфликт, он плавно вернет существующую, устраняя состояния гонки без сложной логики приложения или явных блоков транзакций.

Эта функция — находка для критически важных высоконагруженных рабочих процессов. Подумайте о создании учетных записей пользователей, добавлении уникальных тегов к контенту или обработке идемпотентных API-запросов без страха дублирования записей. ON CONFLICT DO SELECT делает ваш код чище, надежнее и значительно производительнее, позволяя разработчикам сосредоточиться на функциях, а не на защитном программировании базы данных.

Postgres всегда был рабочей лошадкой для данных, но его подход к операциям UPDATE и DELETE создавал коварную проблему: раздувание таблиц (table bloat). Каждая модификация оставляет после себя «мертвые» строки, и хотя VACUUM помечает это пространство как пригодное для повторного использования, он никогда фактически не возвращает его операционной системе. Разработчики были вынуждены мириться с постоянно растущим использованием диска — скрытым налогом на их инфраструктуру.

Postgres 19 наконец-то предлагает встроенное решение: новую команду REPACK. Это не просто небольшая настройка; это прямая атака на раздувание, переписывающая всю таблицу и связанные с ней индексы в новый компактный файл. Это означает реальное освобождение дискового пространства, что является настоящей победой для всех, кто управляет большими базами данных.

Что особенно важно, REPACK позволяет избежать блокировки всей таблицы, которая делала VACUUM FULL непригодным для использования в производственных системах. С опцией CONCURRENTLY приложения могут продолжать чтение и запись данных без помех во время выполнения операции. Это устраняет необходимость в сторонних расширениях, таких как pg_repack, значительно упрощая обслуживание базы данных.

Прежде чем радоваться, обратите внимание на нюанс: REPACK требует наличия достаточного свободного места на диске для временного хранения второй копии таблицы и всех её индексов. Это небольшая цена за возможность освободить место без простоев. Подробнее о предстоящих функциях читайте в официальном анонсе: PostgreSQL 19 Beta 1 Released!.

Postgres 19 предлагает ряд тактических улучшений для разработчиков и администраторов баз данных, оптимизируя рабочие процессы и повышая производительность. Одной из ключевых новинок является PG_PLAN_ADVICE — новый модуль, предназначенный для стабилизации выполнения запросов. Он позволяет зафиксировать быстрый план выполнения запроса и «закрепить» его, предотвращая выбор планировщиком неоптимальных путей, которые могут снизить производительность со временем. Больше никаких загадочных замедлений после обновлений или изменения данных.

Эргономика для разработчиков значительно улучшилась. Вам больше не нужно утомительно повторять каждый неагрегированный столбец из списка SELECT в предложении GROUP BY — это долгожданное упрощение, которое делает SQL чище. Кроме того, команда COPY теперь напрямую поддерживает экспорт данных в JSON, что является небольшим, но важным улучшением для инженеров данных.

Производительность обслуживания также существенно возросла. Операции VACUUM, критически важные для очистки неиспользуемого пространства, теперь используют параллельные рабочие процессы для очистки индексов. Это означает сокращение времени простоя и ускорение циклов обслуживания для больших таблиц, что напрямую решает одну из исторических проблем Postgres.

Наконец, JIT compilation теперь включается по выбору и по умолчанию отключена. В предыдущих версиях JIT часто активировался для запросов, которые не получали от этого выгоды, а иногда даже приводил к снижению производительности из-за неточных оценок стоимости. Отключение по умолчанию гарантирует, что JIT будет использоваться только тогда, когда он явно настроен для подходящих тяжелых запросов, что защищает общую производительность системы.

Какая функция является главной в Postgres 19?

Главной функцией является нативная поддержка SQL/PGQ (Property Graph Queries), позволяющая разработчикам запрашивать реляционные данные с использованием графоподобного синтаксиса, что упрощает сложные соединения (joins).

Является ли Postgres 19 заменой специализированным графовым базам данных, таким как Neo4j?

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

Чем REPACK CONCURRENTLY отличается от VACUUM FULL?

VACUUM FULL блокирует таблицу на всё время выполнения, вызывая простой. REPACK CONCURRENTLY переписывает таблицу для освобождения дискового пространства без длительной монопольной блокировки, позволяя таблице оставаться доступной для чтения и записи во время операции.

Какую проблему решает ON CONFLICT DO SELECT?

Она решает распространенную проблему «получить или создать» с помощью одного атомарного оператора. Это позволяет вставить строку, если она не существует, или выбрать существующую строку, если она есть, в рамках одной транзакционно-безопасной операции, исключая состояние гонки (race conditions).