OSSEVA FOR POSTGRESQL
Your Postgres version is EOL. Your data isn't going anywhere.
OSSeva backports security and data-corruption fixes to PostgreSQL 11, 12 and 13 now, and to 14 when community support ends on 12 November 2026. Patched builds install like a minor release, on the same data directory, under Patroni or repmgr, with migration planning and audit-ready documentation when you need them.
Last reviewed
Trusted globally by enterprises
Why now
PostgreSQL 14 ends on 12 November 2026
The PostgreSQL project supports each major version for five years. The final 14.x minor release is scheduled for 12 November 2026, and after that the community publishes no more security, bug or data-corruption fixes for 14. On Amazon RDS and Aurora, standard support for 14 runs to 28 February 2027 and paid Extended Support starts on 1 March 2027. Self-managed servers have no such cover unless you arrange it.
11, 12 and 13 already miss fixes
The August 2026 minor releases fixed 28 CVEs, and postgresql.org lists 24 of them as fixed in 14.24, 16 of those scored 7.0 or higher. The advisories name supported versions only, and postgresql.org states that no further security patches are made available for versions that are end of life. A server on 13, 12 or 11 gets nothing from that release unless someone backports the fixes.
Major upgrades take longer than the window
A major-version upgrade means an extension audit, query regression tests, a rehearsal of pg_upgrade or logical replication, and a change window on every cluster. Estates with dozens of clusters rarely finish in one quarter. Patched builds keep the servers you cannot move in time covered while the upgrade runs at a safe pace.
Oracle exit customers need a landing zone
Enterprises migrating off Oracle Database frequently land on PostgreSQL, and those migrations take 12 to 24 months. The Postgres version chosen at the start can reach end of life before the programme ends. OSSeva supports the version you landed on while your team finishes the migration.
Versions covered
All versions below receive active CVE patches from OSSeva. Version numbers in monospace are exact release identifiers.
| Version | Status | Active CVEs |
|---|---|---|
| 11.x(Community EOL, OSSeva patched) | Extended | Clean |
| 12.x(Community EOL, OSSeva patched) | Extended | Clean |
| 13.x(Community EOL, OSSeva patched) | Extended | Clean |
| 14.x(Final community release due 12 Nov 2026; OSSeva patches continue after) | Current | Clean |
| 15.x(Covered on Assure and Operate; Patch continues after 2027) | Current | Clean |
| 16.x | Current | Clean |
| 17.x(Recommended upgrade target) | Current | Clean |
| 18.x(Recommended upgrade target) | Current | Clean |
What you get
Three tiers — pick the level of engagement that matches your team's operational needs and compliance requirements.
OSSeva Patch
Backported security and data-corruption fixes for EOL PostgreSQL.
- Quarterly patched releases aligned with the community minor release schedule
- Signed DEB and RPM packages, tarballs and container images
- Contrib modules rebuilt and tested with every release
- Extension compatibility validation
- Vulnerability disclosure notifications
- Migration planning
OSSeva Assure
Patches plus migration roadmap and compliance documentation.
- Everything in Patch
- Major-version migration planning to 17 or 18
- Performance and vacuum configuration audit
- Compliance attestation package
- Oracle-to-Postgres migration design
- 24/7 managed operations
OSSeva Operate
Full DBA-level managed operations for your Postgres fleet.
- Everything in Assure
- 24/7 replication and failover monitoring
- Patroni, repmgr and DCS quorum monitoring
- Automated VACUUM and analyze tuning
- 15-minute P1 incident response SLA
- Point-in-time recovery testing
- Quarterly capacity reviews
All tiers priced per cluster/application — not per core. Contact for pricing →
How it installs
OSSeva artifacts arrive via your existing package infrastructure. Pull the patched version the same way you pull upstream today — just from the OSSeva registry.
curl -fsSL https://packages.osseva.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/osseva.gpg
echo "deb [signed-by=/usr/share/keyrings/osseva.gpg] https://packages.osseva.io/postgresql $(lsb_release -cs) main" \
| sudo tee /etc/apt/sources.list.d/osseva-postgresql.list
sudo apt update && sudo apt install postgresql-13-osseva-- Major and minor version of the running server
SELECT version();
SHOW server_version_num;
-- Extensions to validate against the patched build
SELECT extname, extversion FROM pg_extension ORDER BY extname;patronictl -c /etc/patroni/patroni.yml list pg-main
# On each replica host, install the patched packages, then:
patronictl -c /etc/patroni/patroni.yml restart pg-main pg-node2 --force
# Move the primary role to an updated replica
patronictl -c /etc/patroni/patroni.yml switchover pg-main --candidate pg-node2 --force
# Update the former primary and restart it as a replica
patronictl -c /etc/patroni/patroni.yml restart pg-main pg-node1 --forceFrequently asked questions
What is PostgreSQL extended support?
PostgreSQL extended support is a supply of security and data-corruption fixes for a major version after the PostgreSQL Global Development Group stops releasing them. The community supports each major version for five years. OSSeva takes over at that date for self-managed servers, backporting fixes from the supported branches to 11, 12, 13 and, from 12 November 2026, 14.
Which PostgreSQL versions does OSSeva patch?
PostgreSQL 11, 12 and 13 today, and 14 from the community end-of-life date of 12 November 2026. PostgreSQL 15 is covered on the Assure and Operate tiers now, and Patch subscriptions continue fixes on 15 after 11 November 2027. Versions 16, 17 and 18 still receive community minor releases.
When does PostgreSQL 14 reach end of life?
12 November 2026, five years after its first release on 30 September 2021. The final 14.x minor release is scheduled for that day. Servers still on 14 afterwards need an upgrade, a managed service's own extended support, or a patched build.
What does a patched OSSeva PostgreSQL build include?
Each build is the last community minor release for that major version plus backported fixes for the security and data-corruption issues fixed on the supported branches since. That covers the core server, the client tools such as pg_dump and psql, libpq and the contrib modules. The build is signed and ships as DEB and RPM packages, a tarball and container images.
Does installing a patched build need pg_upgrade or a dump and restore?
No. A patched build stays on the same major version, so it installs the way a community minor release does: stop the server, replace the binaries, start it again on the same data directory. In a replicated cluster, update the replicas first, switch over, then update the former primary.
Are extensions such as PostGIS, TimescaleDB and pgvector covered?
Compatibility is covered, extension code is not. OSSeva tests that the extensions you run still load and pass their checks against each patched build. Security fixes inside a third-party extension sit with that extension's maintainers, and OSSeva tells you which fixes it carries and which it does not before you sign.
How are patched builds delivered?
As signed DEB and RPM packages, tarballs and container images, delivered through your own repository manager or registry. Packages are built per major version, so a server moves to the patched build without changing its data directory or configuration.
Do patched builds work with Patroni?
Yes. Patroni manages the PostgreSQL binaries you install, so a patched build rolls through the cluster like any minor update: replicas first, then a switchover, then the former primary. OSSeva also patches the store Patroni keeps its leader key in when that is an end-of-life ZooKeeper, etcd 3.4 or older, or an MPL-licensed Consul release.
Do patched builds work with repmgr?
Yes. repmgr packages must match the PostgreSQL major version, and the patched build keeps that major version, so the repmgr package and repmgrd configuration stay as they are. repmgr 5.5 supports PostgreSQL 13 to 18, so clusters on 11 or 12 run an older repmgr release, which belongs in the upgrade plan.
How is this different from RDS or Azure extended support?
Managed-service extended support covers instances on that service only. Amazon RDS and Aurora charge per vCPU per hour for each instance in Extended Support, including Multi-AZ standbys. OSSeva covers self-managed PostgreSQL on your own servers, VMs and Kubernetes, and estates moving off a managed service.
Should we upgrade instead of buying extended support?
Upgrade wherever you can do it safely. 17 (supported to November 2029) and 18 (to November 2030) are the sensible targets. pg_upgrade crosses several major versions in one step, from 9.2 onwards, and logical replication cuts the switchover to seconds. Extended support is for the clusters that cannot move before their date.
Can you help us migrate from Oracle Database?
Yes. Oracle-to-Postgres migration design is included in OSSeva Assure, covering schema conversion, query compatibility analysis and the application-layer migration strategy.
Ready to get PostgreSQL patched and supported?
Start with a 45-minute discovery call. We confirm your version coverage, scope the engagement, and have you onboarded within your first quarter.