У каждого релиза 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_ordersMERGE PARTITIONS (orders_2026_q1, orders_2026_q2)INTO orders_2026_h1;-- Разделяем партицию третьего квартала на месячные интервалыALTER TABLE customer_ordersSPLIT 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_graphVERTEX 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 ALLSELECT category, manufacturer, COUNT(*) AS total_items, AVG(price) AS avg_priceFROM inventory_productsGROUP 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 SELECTRETURNING 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, чтобы не пропустить свежие обновления и полезные материалы.
ссылка на оригинал статьи https://habr.com/ru/articles/1061338/