PostgreSQL 19 Release Candidate 1 shipped on October 15, 2026. General availability is scheduled for November 19, 2026, with RC 2 expected on November 12.

The official announcement states that RC 1 will be "mostly identical" to the initial GA release, with some additional fixes possibly applied before then.

What RC 1 actually contains

The official announcement lists six categories of fixes applied since Beta 4:

  • Several fixes for REPACK (CONCURRENTLY)
  • Several fixes for pg_plan_advice
  • Several fixes for new query planner optimizations that rely on whether an expression can be NULL
  • Several fixes for the automatic enablement of logical replication when wal_level is set to replica
  • Fix postgres_fdw statistics import to run as the owner of the foreign table instead of the user running ANALYZE
  • Fix COPY (query) TO ... (FORMAT json) to use the query's column names, including aliases, as the JSON keys instead of the table's column names

These are the actual changes documented in the RC 1 release notes. This article does not reproduce or retest them.

The "AI found too many bugs" narrative

A story circulating in tech media on November 2 claims that AI tools discovering bugs have delayed PostgreSQL 19's release. The claim traces to PostgreSQL committer Robert Haas's blog analysis, which compares the same period between 2025 and 2026: 724 fix commits applied to the new stable branch grew to 1,169.

This causal claim is not verified.

First, the PostgreSQL project does not tag commits with whether they were discovered by LLM tools. There is no official mechanism to distinguish "AI-discovered" bugs from manually found ones.

Second, no official count exists for the proportion of the 1,169 commits that were actually discovered through AI-assisted testing.

Third, increased bug reports do not necessarily indicate declining quality. Finding and fixing more bugs could reflect a healthier project with more active contributors and testing pipelines.

Should you wait for GA?

RC 1 is "nearly GA." Unless a critical issue is discovered, RC 2 will ship on November 12 and GA on November 19.

The upgrade path remains the same: pg_upgrade or pg_dump / pg_restore.

What to check in RC 1

If you test RC 1 in a staging environment, pay attention to these changes:

The postgres_fdw statistics import permission change could affect existing external table reference queries. The COPY (query) TO ... (FORMAT json) column name change means JSON keys now reflect query column names (including aliases) rather than table column names, so any JSON parsing logic that depends on table column names needs review.

Multiple fixes to REPACK (CONCURRENTLY) and pg_plan_advice mean that if your production environment experienced issues in these areas, applying RC 2 or GA may be the safer choice.

This analysis is based on the RC 1 announcement. It does not include test results from our environment.

For deeper analysis of performance improvements and new features, consider how database upgrade strategies connect to the search system architecture covered in the Practical RAG Design course. The paid course below does not cover PostgreSQL versions specifically and does not guarantee upgrade or migration methods.