tracking: PostgreSQL 19 readiness — CI matrix + feature audit + incremental rollout

[devopam]

Background

PostgreSQL 19 Beta 1 was released on 2026-05-15: https://www.postgresql.org/about/news/postgresql-19-beta-1-released-3313/

Final release is typically 4-6 months after Beta 1 (so ~September-November 2026). Cloud providers and managed-Postgres vendors usually have PG 19 GA within 30-60 days of release. MCPg should be ready on day one.

This issue tracks the readiness audit and rollout.

Proposed scope

Phase 1 — CI + compatibility surface (small, fast)

• Add pg:19beta1 to the CI matrix in .github/workflows/*.yml alongside the existing PG 14-18 jobs. Tag as allow_failures until GA, then promote to required.
• Build a scratch/pg19/ docker image off postgres:19beta1 for local testing.
• Run the full unit + integration suite against PG 19 Beta and triage any failures (likely some pg_stat_* view shape changes from §3 below).
• Update version-range strings in pyproject classifiers and README.

Phase 2 — feature audit

Walk each highlighted PG 19 feature against MCPg's existing tool surface. For each, decide: expose via new tool, extend existing tool, or defer.

Per the Beta 1 release notes, the features most relevant to MCPg are:

PG 19 feature	MCPg surface	Decision
Asynchronous I/O subsystem	New io_method GUC; new pg_stat_io columns	Extend read_pg_stat_io; add recommend_io_method advisor
OAuth-based authentication	pg_hba.conf extension	New tool surface? Doc only? Decide
MERGE ... RETURNING improvements	run_write allow-list expansion	Tiny; verify the safety-driver accepts new syntax
GIN OR-of-AND filtering optimisations	Query planner changes only	No tool surface; performance bench only
Skip scans for B-tree indexes	Planner change	Update recommend_indexes advisor to factor in skip-scan eligibility
Partition expression-based bounds	Already partitioning-aware	Verify list_partitions + partman_* still work; possibly extend compare_schemas
CHECK constraints NOT VALID + validation	DDL surface	New tool: validate_check_constraint
Logical replication: per-table progress	Replication tooling	New tool: read_logical_replication_progress
New pg_stat columns (vacuum I/O timing, etc)	Multiple advisors	Extend audit_database, check_database_health, run_advisors
pg_get_acl() SQL function	Privilege introspection	Extend list_grants to use the new accessor (faster, more accurate)
Hash function for interval type	Vector / partitioning corner	Verify partition-by-hash on interval columns works through partman_create_parent
VACUUM: opportunistic freeze + faster pages	run_maintenance	Update tool description to reflect PG 19 behaviour
Sequence: per-sequence access methods	DDL surface	Likely defer; no MCPg user demand yet

Compile the audit into docs/plans/pg19-readiness.md with one section per feature carrying:

• Spec link
• Existing surface affected (if any)
• New tool name (if any)
• Required vs nice-to-have
• Test plan

Phase 3 — incremental landing

Land features in small PRs as PG 19 progresses through Beta → RC → GA:

• Beta 1 (now): CI matrix + compatibility shims for shape changes (probably ~3 days work).
• Beta 2/3: Feature-specific PRs based on Phase 2 audit. ~5-10 PRs depending on how many features we expose.
• RC: Final pass; promote PG 19 to a required CI job.
• GA + 1 week: Cut an MCPg release that advertises PG 19 support in the README + PyPI classifiers.

Why land now rather than wait

1. The compatibility check is cheap. Most failures will be shape changes in pg_stat_* views or new columns mid-SELECT * queries. Fixing them in advance avoids panic when a user upgrades to PG 19 in their staging environment.
2. Skip-scans alone are worth the early read. recommend_indexes becomes meaningfully more accurate when it can suggest indexes that benefit from the new B-tree skip-scan optimisation.
3. AIO is genuinely new operational surface. Operators will want guidance on io_method=io_uring vs worker vs sync. Having recommend_io_method ready at GA is differentiation.
4. Community signal. Being explicitly "PG 19 day-one ready" on the PyPI page is a stronger positioning than waiting.

Out of scope (for this issue)

• Major MCPg API changes — PG 19 is additive for us. If a feature requires breaking changes, file a separate issue.
• New cloud-provider integrations (RDS / Cloud SQL / Crunchy) — handled by the existing config surface.

Sequencing

Land after #119 (pg_prewarm). The pg_prewarm advisor work establishes the cross-advisor coordination pattern (#119 has to consider recommend_indexes), which is exactly what the PG 19 skip-scan changes to recommend_indexes will benefit from.

Acceptance

Phase 1:

• CI matrix runs PG 19 Beta 1 (allow_failures until GA).
• All existing unit + integration tests pass against PG 19 Beta.
• README + pyproject classifiers list PG 19 in the supported-versions range.

Phase 2:

• docs/plans/pg19-readiness.md filed and merged, covering every Beta 1 feature with a clear decision.

Phase 3:

• Tracked through the per-feature PRs that this issue spawns.

---

Refs: requested in the v0.6.2 → next-version planning conversation. Beta 1 release notes: https://www.postgresql.org/about/news/postgresql-19-beta-1-released-3313/