Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article4 min readViews1

PostgreSQL 14 No Longer Supported: What Website Owners Need to Check

On November 12, fixes for 52 PostgreSQL vulnerabilities were released, along with the final release for branch 14. Check your migration plan, extensions, and backups.

Comments 0

A man places a backup cartridge into an open metal archival cabinet in a bright room
In this article

On November 12, 2026, the PostgreSQL project released security updates and ended support for branch 14. If your website, online store, or integration service database runs on PostgreSQL, ask your administrator to verify the version and update plan. For branch 14, you must plan a transition to a supported major version; users of incremental backups must separately verify the procedure for creating a new full backup.

What Was Released and What Changed

PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 have been released. According to the project, the release fixes 52 vulnerabilities and over 140 bugs. This is a general list: affected versions and conditions vary, so one cannot assume each of the 52 issues applies to every installation. The security advisory itself does not prove that a specific database was successfully compromised.

14.25 is the final release of PostgreSQL 14. The community will no longer issue security or bug fixes for this branch. Installing 14.25 addresses the issues fixed in this release but does not extend support for the branch. If support is provided by a separate vendor, verify the duration and scope of their obligations, as they may differ from community support.

In-branch updates and migration to a new version are distinct tasks

Updating within a single major version typically does not require dumping and reloading the entire database. However, the administrator must first read the release notes: for some configurations, additional actions are required. Migration from version 14 to another major version requires a separate migration plan, application and extension compatibility checks, a data transfer method, and a rollback procedure in case of failure.

The fixes change the handling of composite data types. Release notes warn that full protection will require recompiling C-language extensions and, for some extensions, modifying the source code. This must be coordinated with the package and extension providers. Do not disable new security checks for a faster startup.

Pay special attention to backups and indexes

Users of built-in incremental backups in PostgreSQL 17 and 18 face a specific warning about errors that can corrupt such backups. After applying the fixes, the project recommends creating a new full backup and using it as the basis for subsequent incremental backups. Do not rely on the previous chain as a verified recovery path; coordinate a recovery test for the new backup.

Errors that can corrupt individual indexes and affect query results have also been fixed. Administrators must match their configuration against the notes for their specific branch and determine which indexes require rebuilding. A universal command for all databases is not suitable: the scope of work and impact on availability depend on the specific project.

What to request from the database administrator

  • Confirmation of the running database server version and a list of dependent sites and integrations, not just the version of the installed client utility.
  • The full package number and details of the vendor's patches. If the vendor backports patches into a package with an older base version number, their documentation is required.
  • A backup and a recovery plan prior to changes; agreed-upon maintenance windows, necessary restarts, and additional actions from the release notes.
  • Verification of key operations after maintenance: login, catalog search, order saving, data exchange, and background tasks—based on your project's functions.

This news applies to projects that actually use PostgreSQL. Merely having a VPS, virtual hosting, or 1C-Bitrix does not mean that this specific DBMS is in use. The simultaneously released PostgreSQL 19 RC 2 remains a pre-release; the public release 19 is only scheduled for November 19, and you should not replace a production database based on this news.

Information verified on November 12, 2026, at 21:08 MSK. The release date is November 12; the exact time is not specified in the announcement. No geographical restrictions for project fixes have been declared.

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.