Release Date: 2025-12-26
This release is based on PostgreSQL 18.1 and includes all the new features introduced in PostgreSQL 18, as well as bug fixes implemented in PostgreSQL 18.1 update. For the detailed description, see PostgreSQL 18, and PostgreSQL 18.1 Release Notes.
For the list of extension modules and utilities specific to Postgres Pro Enterprise, as well as the main user-visible core changes over vanilla PostgreSQL, see Section 2. As compared to Postgres Pro Enterprise 17.7.1, the following differences are worth mentioning:
Added the ability to create tables that are divided into partitions
by specifying a foreign key. The foreign key is used as a reference
to the parent partitioned table and is defined by the
PARTITION BY REFERENCE
clause.
Added the
pg_relation_logical_blocks
function to compute the disk space used by relation forks for both
compressed and uncompressed tables.
Added the new OLD_PASSWORD_TIME and
OLD_PASSWORD_MAX parameters for the CREATE PROFILE
and ALTER PROFILE
commands. These parameters are required to enable authentication with
the previous password. OLD_PASSWORD_TIME specifies
for how long the previous password can be used for authentication
alongside the new one. OLD_PASSWORD_MAX specifies
the number of attempts to authenticate with the previous
password before it is locked. The oid
and passloginattempts fields were added to
the pg_role_password
catalog, and the pfloldpasswordtime
and pfloldpasswordmax fields were added to
the pg_profile
catalog to display information related to previous passwords.
Added the new compute_plan_id configuration
parameter that allows enabling and disabling in-core computation of
query plan identifiers. Also added the plan_id
field to the
pg_stat_activity
view to display plan identifiers.
Added the new extra_query_transformations
configuration parameter that controls additional query tree
transformations. This parameter replaces the
enable_any_to_lateral_transformation and
enable_extra_transformations parameters that
were removed.
Added the append_optimized storage parameter that enables or disables bulk insertion into tables. This functionality allows reducing the time spent searching for buffers in shared memory and generating fewer WAL records.
Implemented the pg_temp_default tablespace for
default storage of temporary objects, such as temporary tables,
indexes on such tables, or temporary files that are created, for
example, to store intermediate query results. This tablespace is
created by default at cluster initialization. Besides, the
spcpersistence column is added to the
pg_tablespace
catalog. Temporary tablespaces can store only temporary objects,
while permanent tablespaces cannot store temporary objects. You can
now also make a permanent tablespace temporary using the
ALTER TABLESPACE command.
Implemented the following enhancements for the k-NN search:
Minimized the number of “primitive” index scans
during index-only scans in cases when the ORDER
expression argument is outside the bounds of ScalarArrayOp conditions.
Added the ability to merge several ScalarArrayOp conditions
specified using the AND logical operator.
Allowed casting from the xid data type to the
xid8 type.
Changed the Adaptive Query Execution
behavior related to plan identifiers. Now for AQE
operation, the compute_plan_id configuration
parameter should be set to auto (default) or
on to enable in-core computation of plan identifiers.
Otherwise, AQE is disabled.
Improved the BiHA solution to provide the following features and optimizations:
Upgraded biha to version 1.7.
Implemented cascading replication for BiHA clusters that helps to decrease workloads on the leader and allows deploying BiHA clusters in different data centers. You can configure cascading replication when initializing a new BiHA cluster or GDBiHA cluster by means of the updated bihactl utility and then modify cascading replication configuration using max_replicas, preferred_roles, priority parameters and corresponding functions. If any replication source fails, BiHA re-configures cascading replication automatically.
Implemented experimental functionality that allows to unite nodes of the BiHA cluster into segments (logical nodes) that can be located in geographically distributed data centers. Data is transferred between segments via a single thread between the leader and the front follower — physical nodes located in the leader segment and the follower segment respectively. If the leader or front follower fails, data replication is re-configured automatically. If required, you can set the leader segment manually. For more information, refer to Multi-Level Geographical Distribution and Disaster Resilience.
Implemented interoperability with pg_createsubscriber. You can use the pg_createsubscriber utility to reduce downtime when migrating your BiHA cluster from Postgres Pro Enterprise version 17.X to version 18.X.
Upgraded the bihactl utility that keeps former functionality and provides support for managing cascading replication and segments for multi-level geographical distribution and disaster resilience.
Added the biha.super_status_v view — the extended version of the biha.status_v view that additionally displays data for GDBiHA cluster.
Enhanced the logging
functionality to provide better usability and log message clarity.
Added separate logging levels for
Postgres
Controller and
Config
Controller components.
Implemented the service mode functionality managed by the biha.service_mode function. The service mode allows to temporarily pause BiHA operation. This may be required when you modify configuration parameters and want to ensure changes are applied on all cluster nodes.
Added the biha.monitoring function that allows monitoring the current status of BiHA cluster nodes. You can call this function from any node.
Added watchdog — a
special protection mechanism that helps to prevent node hanging
and split-brain issues. You can manage watchdog
using the biha.watchdog_timeout
configuration parameter.
Inherited the vanilla implementation of automatic removal of some
unnecessary table self-joins. The corresponding
enable_self_join_removal configuration parameter
is removed; use enable_self_join_elimination
instead.
Inherited the vanilla implementation of automatic transformations of
x IN (VALUES (...), (...)) constructions into
x = ANY([...]) constructions to get efficient
query plans. The pgpro_planner extension is no
longer required to perform these transformations.
Removed the deprecated pgpro_version,
pgpro_edition, and pgpro_build
functions. Use the pgpro_version,
pgpro_edition, and pgpro_build
configuration parameters instead.
Postgres Pro binary packages for Linux systems for Elbrus CPU architecture are not available yet.
Ended support for Debian 11.
Upgraded aqo to version 4.0 to implement optimizations that improve performance and significantly reduce overhead of query planning.
Upgraded pgpro_multiplan to change the logic to
calculate plan identifiers for the planid
field of the pgpro_multiplan_stats
view. Now you should set the compute_plan_id
configuration parameter to on to enable in-core
computation of plan identifiers, which is used by
pgpro_stats.
Otherwise, the values of this field are set to 0.
Upgraded the proxima extension to provide the following features and enhancements:
Added the experimental KVik module to proxima. Designed for systems with high data-reading workloads, KVik provides in-memory caching of data stored in Postgres Pro databases and fast operation with cache via RESP (Redis Serialization Protocol). The main features of KVik are the following:
high-performance data reading
support of RESP commands, such as SET,
GET, and DEL
automatic invalidation of cached data when modified via
INSERT, UPDATE, and
DELETE statements in
Postgres Pro databases
automatic data update in Postgres Pro
databases when modified in cache via SET and
DEL operations
Implemented the built-in load balancer based on the previously implemented workload distribution functionality. The load balancer distributes read-only workloads across cluster replicas by the defined load balancing algorithm.
Upgraded the apache_age extension to version 1.6.1.
Upgraded orafce to version 4.16.3.
Upgraded pg_filedump to version 18.1.
Upgraded pg_hint_plan to version 1.8.0.1.
Upgraded pg_probackup to version 2.8.12 Enterprise.
Upgraded pgpro_controldata to version 18.2.0.
Upgraded pgpro-orautl to version 2.2.
Upgraded pgvector to version 0.8.1.
Upgraded tds_fdw to version 2.0.5.
Postgres Pro is no longer compatible with the citus extension.
Removed the deprecated vops extension.
You can migrate to Postgres Pro Enterprise 18 from the same or a previous version of PostgreSQL (that is supported by the upgrade method chosen) or Postgres Pro Standard/Postgres Pro Standard Certified and from a previous version of Postgres Pro Enterprise/Postgres Pro Enterprise Certified. The same holds for migration to Postgres Pro Enterprise Certified 18. See Section 18.6 for the methods to upgrade your database cluster. Consult the Postgres Pro Enterprise support team if you experience issues during migration. Backward migration is not supported. Note that migration from Postgres Pro Enterprise to Postgres Pro Enterprise Certified of the same major version (or vice versa) is an update between Postgres Pro compatible versions (see Section 18.6 for more details).
To migrate from PostgreSQL, Postgres Pro Standard, or Postgres Pro Enterprise release based on a previous PostgreSQL major version, make sure to install its latest available minor version and then perform a dump/restore using pg_dumpall or use the pg_upgrade utility.
If you choose to run pg_upgrade, make sure to
initialize the new database cluster with compatible parameters.
In particular, pay attention to
the checksum settings
in the cluster you are migrating from.
If pg_upgrade creates any SQL files in
its current directory, run these files to complete the upgrade.
You cannot use the pg_upgrade --swap
option to upgrade to Postgres Pro Enterprise from
PostgreSQL or Postgres Pro
Standard due to incompatibility of heap and FSM page
headers and from Postgres Pro Enterprise lower than
version 14 due to incompatibility of the visibility map page format.
When migrating from PostgreSQL or
Postgres Pro Standard, make sure to
pay special attention to implementation specifics of
64-bit transaction IDs. If
you have used explicit casts to 32-bit integers when handling transaction
IDs, you have to replace them with casts to bigint since
64-bit transaction IDs are of the bigint type.
For the instructions on migrating your BiHA cluster to version 18, see migration instructions for BiHA.
To avoid conflicts, do not use the postgrespro-ent-18
package to install the new Postgres Pro
binaries. Use the individual packages instead.
In this case, server autostart needs to be enabled manually, if required.
For details on the available packages and installation instructions,
see Chapter 17.
For other upgrade requirements imposed by vanilla PostgreSQL, see Section E.3.