PostgreSQL 19 Beta 3 Is Out: Patch Now, PG14 EOL in 89 Days

On August 13, the PostgreSQL Project released coordinated security updates across every active supported version — 18.6, 17.11, 16.15, 15.19, and 14.24 — patching 28 vulnerabilities, seven of them scoring 8.8 on CVSS. Alongside it came PostgreSQL 19 Beta 3, which is now feature-complete. And buried in the release notes is a date developers need to write down: PostgreSQL 14 reaches end of life on November 12, 2026. That is 89 days from today.

Patch These Vulnerabilities Now

The August 13 security releases are not optional maintenance. Seven of the 28 CVEs rate 8.8 (High) on CVSS v3.1, and several are remote code execution vulnerabilities enabled by heap buffer overflows — the kind that let an attacker execute arbitrary code as the OS user running your database server.

The notable ones:

• CVE-2026-14669: Heap buffer overflow in to_char(timestamptz). A long POSIX timezone abbreviation triggers an undersize allocation followed by an out-of-bounds write. Anyone who can influence timezone input to a Postgres function can exploit this.
• CVE-2026-14664: Regexp heap buffer overflow. Same class of bug, different code path.
• CVE-2026-2005 / CVE-2026-2006: A pgcrypto encoding bug chain that ends in RCE.

The pattern across most of these: integer wraparound creates an undersize memory allocation, then an out-of-bounds write follows. These are classic RCE primitives, and they exist in code paths that real applications hit. See the full PostgreSQL security advisory for the complete CVE list and severities.

On Debian/Ubuntu, sudo apt update && sudo apt upgrade postgresql-* handles it. On managed services, these patches land during your next maintenance window — check your provider’s schedule if you need it faster.

PostgreSQL 14 Has 89 Days Left

If your team is still running PostgreSQL 14 in production, November 12 is the date that should be on your roadmap. That is when the community stops issuing security patches for version 14. A critical vulnerability disclosed on November 13 will not get a fix for PG14 — ever.

The community EOL is the headline. The financial reality is what will actually force most organizations to move:

• Amazon RDS: Standard support ends February 28, 2027. Extended Support billing starts March 1, 2027 at $0.10/vCPU-hour — on a 16-vCPU instance, that is $1,168 per month in fees for running unsupported software.
• Azure Database for PostgreSQL: Extended Support billing began August 1, 2026. Azure’s stance is the most aggressive — instances are automatically enrolled in paid extended support.
• Google Cloud SQL: Extended support starts February 1, 2027, after which Cloud SQL will automatically upgrade instances to the current default version during maintenance.

The migration target depends on your priorities. PostgreSQL 17 is the safe choice — broadly supported across cloud providers, stable, and covers you for years. PostgreSQL 18 gives you the async I/O subsystem that has shown up to 3x storage read improvements, but it is a newer major version. Upgrading directly from 14 to 18 is supported via pg_upgrade; always run pg_upgrade --check as a dry run before the actual migration. Managed service users can use their provider’s major version upgrade wizard, which handles the complexity and keeps a rollback window via snapshots. The PostgreSQL EOL schedule shows the full version timeline.

What Is New in PostgreSQL 19 Beta 3

Beta 3 is the feature-complete milestone. What is in Beta 3 is what ships in the final release, expected Q4 2026. Three features are worth knowing about now.

LZ4 Becomes the Default TOAST Compression

LZ4 support landed in PostgreSQL 14. PostgreSQL 19 finally makes it the default. The default_toast_compression GUC switches from pglz to lz4, and benchmarks from Crunchy Data justify the change: LZ4 processes TOAST inserts roughly 8x faster than pglz (6 ms versus 50 ms for a 2,000-row batch of 10 kB values). Existing data stays compressed with pglz; only new TOAST data uses LZ4. No action needed on existing databases — the improvement is automatic on upgrade.

REPACK CONCURRENTLY Replaces pg_repack for Most Cases

Table bloat has always been painful. VACUUM FULL reclaims space but requires an access-exclusive lock, taking your table offline. The pg_repack extension solved this with an online rebuild approach, but it required installing and maintaining a third-party extension. PostgreSQL 19 bakes the capability in natively:

-- Online table rebuild in PostgreSQL 19
REPACK (CONCURRENTLY, ANALYZE, VERBOSE) orders;

The process builds a clean copy of the table under a shared update exclusive lock (the same level as VACUUM), captures ongoing changes, replays them onto the new copy, then performs a brief lock for the final swap. The table remains readable and writable throughout. Limitations apply: it does not work on unlogged tables, partitioned tables, or tables without a primary key.

SQL/PGQ: Graph Queries on Your Existing Tables

PostgreSQL 19 adds SQL/PGQ, the graph query extension from the SQL:2023 standard. The pitch: define a property graph over your existing relational tables and query it with pattern matching — no new database, no extension, no data migration. Neon’s SQL/PGQ guide has the full syntax reference.

-- Define a property graph
CREATE PROPERTY GRAPH orders_graph
  VERTEX TABLES (customers, products)
  EDGE TABLES (purchases SOURCE customers DESTINATION products);

-- Query it with pattern matching
SELECT * FROM GRAPH_TABLE (orders_graph
  MATCH (c IS customers)-[IS purchases]->(p IS products WHERE p.category = 'Electronics')
  COLUMNS (c.name, p.title));

This covers fraud detection, recommendation engines, org chart traversal — any relationship-heavy query that would otherwise require recursive CTEs or a specialized graph database. The beta supports fixed-depth pattern matching; variable-length path queries are planned for a future release.

What to Do This Week

• Apply the security patches — 18.6, 17.11, 16.15, 15.19, or 14.24, depending on your version. Do not wait for the next maintenance cycle.
• Audit your PG14 instances — inventory everything running version 14, prioritize production databases, and put a migration timeline on the roadmap now. November 12 is 89 days away.
• Test PG19 Beta 3 — if you are on PG18 or planning to be, Beta 3 is worth running in a non-production environment. File bugs; the PostgreSQL Project needs them before GA.