У каждого релиза Postgres свой характер.

Одни релизы строятся вокруг громкой фичи. Другие решают давнюю проблему. Третьи содержат небольшие улучшения, которые замечаешь только после обновления: повседневная работа становится проще. Почти каждый релиз также повышает производительность.

В Postgres 19 есть улучшения на любой вкус. Встроенная команда REPACK CONCURRENTLY упрощает обслуживание крупных рабочих баз данных. SQL-запросы к графам свойств наверняка привлекут много внимания. Логическая репликация становится полноценнее.

Разработчики также улучшили VACUUM, EXPLAIN, COPY, секционирование, мониторинг и планировщик. Эти изменения не так заметны, но упрощают эксплуатацию рабочих систем.

До финального релиза детали могут измениться. Но бета-версия Postgres 19 уже позволяет оценить новые возможности и понять, как они повлияют на разработку и эксплуатацию систем.

REPACK прямо из коробки

Если вы давно работаете с Postgres, то наверняка сталкивались с "раздуванием" таблиц. Чтобы освободить место, перезаписать таблицу или реорганизовать данные, приходилось мириться с блокировкой от VACUUM FULL или CLUSTER.

Эту проблему давно решают расширения, прежде всего pg_repack. Их популярность подтверждает, что пользователям не хватало встроенного инструмента.

Postgres 19 добавляет в ядро команду REPACK с поддержкой REPACK CONCURRENTLY.

Для рабочих баз данных REPACK CONCURRENTLY может оказаться важнее, чем кажется по релиз ноутсам.

Партиционирование становится практичнее

Раньше партиционирование в Postgres требовало знания внутренних механизмов и подводных камней. За последние годы работать с ним стало гораздо проще.

В Postgres 19 партиции можно объединять и разделять.

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

Разделение и объединение партиций позволяет менять архитектуру вместе с системой.

-- Объединяем первый и второй кварталы в одну партицию
ALTER TABLE customer_orders
MERGE PARTITIONS (orders_2026_q1, orders_2026_q2)
INTO orders_2026_h1;

-- Разделяем партицию третьего квартала на месячные интервалы
ALTER TABLE customer_orders
SPLIT PARTITION orders_2026_q3 INTO (
    PARTITION orders_2026_07
        FOR VALUES FROM ('2026-07-01') TO ('2026-08-01'),
    PARTITION orders_2026_08
        FOR VALUES FROM ('2026-08-01') TO ('2026-09-01'),
    PARTITION orders_2026_09
        FOR VALUES FROM ('2026-09-01') TO ('2026-10-01')
);

Архитектура базы данных редко остаётся неизменной. Новые команды помогают адаптировать её без полной перестройки и упрощают многолетнюю эксплуатацию Postgres.

Postgres 19 прямо в IDE

Встроенный DB-клиент OpenIDE уже поддерживает PostgreSQL, Oracle, MySQL и другие СУБД. Через него можно подключиться к базе, изучить структуру схемы, написать и выполнить SQL-запрос, посмотреть результат и запустить EXPLAIN. Всё происходит в той же IDE, где открыт код проекта.

К выходу финальной версии Postgres 19 мы добавим поддержку всех новых возможностей релиза. Команды для работы с партициями, обновлённая логическая репликация, новые функции COPY, SQL/PGQ и другие изменения будут доступны прямо в OpenIDE.

Логическая репликация продолжает развиваться

Логическая репликация остаётся одним из главных направлений разработки Postgres. Её используют для миграций, обновлений, отчётности, перемещения данных, выборочной репликации и обеспечения высокой доступности.

Postgres 19 расширяет логическую репликацию сразу в нескольких направлениях.

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

Новая настройка ALL SEQUENCES позволяет включить в логическую репликацию все последовательности. Postgres также сообщает об ошибках их синхронизации и корректнее обновляет конфигурацию репликации.

При репликации всех таблиц предложение EXCEPT позволяет указать исключения. Это упрощает распространённый сценарий: переносить почти всё, кроме нескольких таблиц.

Настройка wal_level = replica теперь может автоматически включать логическую репликацию при необходимости. Новый параметр effective_wal_level показывает фактический уровень WAL. Это снижает риск ошибок в конфигурации и делает поведение Postgres понятнее.

Логическая репликация остаётся сложным инструментом. Однако с каждым релизом она всё увереннее входит в стандартный набор средств эксплуатации Postgres.

Autovacuum становится умнее и прозрачнее

Vaccum играет важную роль в работе Postgres.

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

Postgres 19 улучшает vacuum в нескольких областях.

Теперь autovacuum может использовать параллельные рабочие процессы. Их количество настраивается глобально и для отдельных таблиц. Это ускоряет обслуживание крупных таблиц и индексов.

-- Разрешаем процессам autovacuum использовать до четырёх
-- параллельных рабочих процессов на глобальном уровне
ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;

Новая система оценки определяет порядок обработки таблиц. Autovacuum выбирает, какая таблица требует внимания и должна обрабатываться следующей. Умная расстановка приоритетов помогает устранить проблему до того, как она приведёт к инциденту.

-- Настраиваем оценку приоритета только для этой таблицы:
-- резко повышаем срочность очистки по вставкам (3.0),
-- а обычную срочность очистки по обновлениям и удалениям снижаем (0.5),
-- поскольку строки удаляются редко.
ALTER TABLE application_logs SET (
    autovacuum_vacuum_insert_score_weight = 3.0,
    autovacuum_vacuum_score_weight = 0.5
);

Представление pg_stat_autovacuum_scores показывает, как autovacuum принимает решения. Представления прогресса очистки и анализа содержат больше данных. VACUUM VERBOSE и журналы autovacuum сообщают об использовании памяти и параллелизме. Отдельный параметр log_autoanalyze_min_duration управляет журналированием автоматического анализа. В результате обслуживание стало прозрачнее.

База данных должна не только выполнять фоновую работу, но и понятно о ней сообщать.

SQL-запросы к графам свойств

Одно из самых интересных нововведений Postgres 19: SQL/PGQ, то есть SQL-запросы к графам свойств.

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

-- Пример графа свойств
CREATE PROPERTY GRAPH store_graph
VERTEX TABLES (
    customers LABEL customer,
    orders LABEL "order"
)
EDGE TABLES (
    customer_orders
        SOURCE customers
        DESTINATION orders
        LABEL placed_order
);

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

Postgres добавляет полезные возможности без перехода на новую архитектуру. JSONB не заменил реляционные таблицы. Полнотекстовый поиск не потребовал отдельной поисковой базы для каждого сценария. Расширения не привели к необходимости создавать форк базы данных. Теперь SQL/PGQ позволяет работать с реляционными данными как с графом.

Главная идея не в том, что Postgres стал графовой базой данных. Важно, что уже выбранная база получила новые возможности.

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

COPY становится ещё полезнее

COPY быстро и надёжно загружает и выгружает данные. Эти операции встречаются повсюду, поэтому даже небольшие улучшения заметно влияют на работу.

Postgres 19 расширяет возможности COPY.

COPY FROM умеет пропускать несколько строк заголовка. Это полезно для CSV-файлов с дополнительными метаданными в начале.

Режим ON_ERROR SET_NULL заменяет недопустимые входные значения на NULL. Теперь не обязательно прерывать всю загрузку или заранее очищать файл.

-- Представьте файл, в котором столбец цены иногда содержат
-- 'N/A' или 'MISSING' вместо числового значения
COPY product_catalog (product_id, title, price_usd)
FROM '/path/to/dirty_products.csv'
WITH (
    FORMAT CSV,
    HEADER,
    ON_ERROR SET_NULL
);

COPY TO может выводить данные в формате JSON, в том числе единым массивом. Команда также напрямую выгружает секционированные таблицы. Раньше для этого требовалось COPY (SELECT ...).

-- Экспортируем всю таблицу напрямую в аккуратно отформатированный,
-- корректный JSON-массив
COPY customers TO '/path/to/customers_export.json'
WITH (FORMAT JSON, ARRAY true);

Каждое из этих изменений упрощает повседневную работу с данными.

Улучшения SQL для повседневной работы

GROUP BY ALL автоматически группирует по всем выражениям целевого списка, кроме агрегатных и оконных функций. Это делает исследовательские и отчётные запросы короче.

-- Использование GROUP BY ALL
SELECT
    category,
    manufacturer,
    COUNT(*) AS total_items,
    AVG(price) AS avg_price
FROM inventory_products
GROUP BY ALL;

Функции lead, lag, first_value, last_value и nth_value получили поддержку IGNORE NULLS и RESPECT NULLS. Теперь предыдущее ненулевое значение в последовательности можно получить без сложных обходных решений.

Конструкция INSERT ... ON CONFLICT DO SELECT ... RETURNING позволяет напрямую возвращать конфликтующие строки. Это делает операции upsert гибче.

INSERT INTO tags (tag_name)
VALUES ('postgres')
ON CONFLICT (tag_name) DO SELECT
RETURNING tag_id;

Postgres также добавляет UPDATE и DELETE FOR PORTION OF для работы с временными данными. Такой синтаксис полезен во многих реальных приложениях.

Улучшения производительности по всем направлениям

В Postgres 19 улучшили планировщик и исполнитель запросов. Особая благодарность Тому Лейну из Snowflake за работу над производительностью и другими компонентами.

Изменения затронули антисоединения, полусоединения, свёртку констант, инкрементальную сортировку с путями добавления, обработку агрегатов до соединений, расчёт селективности соединений и статистику функций.

Главный результат: Postgres лучше распознаёт структуру типичных запросов и выполняет меньше лишней работы.

Часть агрегатов теперь обрабатывается до соединений, поэтому Postgres перебирает меньше строк. Больше вариантов NOT IN и LEFT JOIN преобразуются в эффективные антисоединения. EXPLAIN лучше показывает работу Memoize. Поразрядная сортировка ускоряет сортировку данных. Ограничения внешних ключей проверяются быстрее. Текстовый и CSV-ввод через COPY FROM может использовать SIMD-инструкции.

Для этих улучшений обычно не нужно менять код приложения. Достаточно обновить Postgres, и он чаще выберет эффективный план.

Такие улучшения базы данных особенно ценны.

OpenIDE Pro позволяет разрабатывать проекты на Java, Spring, Python, Go, PHP, JavaScript и TypeScript! А полноценный DB-клиент, поддержка Docker и 300+ плагинов доступны абсолютно бесплатно в маркетплейсе. Пробуйте российскую IDE в деле и подписывайтесь на нас в Telegram или Max, чтобы не пропустить свежие обновления и полезные материалы.