PostgreSQL 19 Beta 1 Release Date Announcement

Overview

This is a release-management coordination message from Jonathan Katz announcing the planned release date for PostgreSQL 19 Beta 1. While not a technical design discussion, it is a critical process milestone in the PostgreSQL development cycle that has significant implications for the state of the codebase and the commitment of in-flight features.

The Role of Beta 1 in the PostgreSQL Release Cycle

PostgreSQL follows a well-established annual release cadence. The transition from development to beta is one of the most consequential moments in each cycle:

1. Feature freeze enforcement: By the time Beta 1 ships, all major features targeting the release must be committed. The beta period is reserved for bug fixes, stabilization, and documentation — not new feature work.
2. Buildfarm validation window: The message explicitly calls out a 4-day buffer (May 30 → June 4) between the commit deadline and the release date. This window exists to allow the PostgreSQL buildfarm — a distributed network of machines running varied OS/architecture/compiler combinations — to exercise the committed code and surface portability or correctness regressions.
3. Open Items triage: The reference to the PostgreSQL_19_Open_Items wiki page is a signal to all active patch authors and committers to check whether their work is listed and whether it is at risk of missing the cutoff.

Architectural Implications

The Beta 1 deadline acts as a forcing function on several categories of work:

• Large, invasive patches (e.g., new executor nodes, planner paths, storage-layer changes, new index access methods) that are still under review face a hard deadline. If not committed by May 30, they slip to PostgreSQL 20.
• Catalog changes: Any modifications to system catalogs (pg_catalog) must land before beta, as post-beta catalog changes create upgrade and pg_upgrade complications.
• Wire protocol or libpq changes: Similarly frozen, as client-side tooling begins testing against beta releases.
• GUC additions or changes: New configuration parameters should be settled before beta to allow documentation and testing.

Key Dates

The 4-day gap is standard practice — enough time for at least one full buildfarm cycle across all registered animals (build targets), plus time for the release management team to produce tarballs, update the website, and coordinate announcements.

What This Means for In-Flight Development

For any patches currently on the pgsql-hackers list that target PostgreSQL 19:

• Patches in "Ready for Committer" state are the highest priority — committers will be triaging these against the deadline.
• Patches still under active review with unresolved design disagreements are at serious risk of deferral.
• Patches with open buildfarm failures or known regressions on specific platforms will likely not make the cut.

The Open Items wiki page serves as the canonical tracker for what still needs resolution. Historically, this page includes items categorized as "Bugs," "Open Issues," and "Decisions Needed," each requiring different levels of attention from different community members.

Context Within PostgreSQL Governance

This announcement comes from Jonathan Katz, who serves on the PostgreSQL Core Team and is actively involved in release management. Release date announcements of this nature are authoritative — they represent coordination between the core team, release management team, and the broader committer pool.