PostgreSQL 19 Beta 1 tests the protocol around the database

PostgreSQL 19 Beta 1 is available on June 4, with previews that include asynchronous I/O improvements and new SQL capabilities. The announcement also identifies a temporary protocol compatibility campaign called grease mode. I find that campaign particularly useful because it asks whether the software between an application and its database follows negotiation rules that future protocol improvements will need.

I still choose PostgreSQL by default for relational work after decades of production use. That preference makes compatibility testing interesting to me beyond the question of whether a new SQL statement works. A database installation can depend on client libraries and a proxy as well as the server. The beta gives users a way to report problems in that connection path before general availability.

A client can ask for something the server does not support

The project's grease explanation describes an unusual aspect of PostgreSQL's protocol. A server must opt out of a requested feature it does not understand. If a client requests a protocol minor version greater than the server supports, the server must send a NegotiateProtocolVersion message identifying the version actually in use. It must also report requested protocol extensions it does not understand.

The expected response is negotiation followed by the rest of the handshake. Rejecting the connection merely because the client requested an unknown extension does not satisfy that rule. Silently proceeding without the required negotiation message also fails to communicate the supported behavior. These distinctions give compatibility testing something more precise to assess than whether an ordinary connection succeeds.

During the PostgreSQL 19 beta cycle, client software checks this behavior more strictly. If it detects a server or proxy that does not follow the rules, it stops and reports a grease error. The wiki says the strict behavior is temporary for this beta campaign. It is therefore important to distinguish a deliberate diagnostic failure from a commitment that the final PostgreSQL 19 release will reject the same connection.

The history explains why the project is doing this. The wiki dates protocol negotiation to 2017 and describes implementations that omit it or implement it incorrectly. An unused negotiation mechanism does not provide much assurance that a later client can use it successfully. Exercising it during a beta gives maintainers evidence about software already deployed in the wider ecosystem.

A proxy belongs in the test environment

For an application that normally connects through a proxy, I would retain that path in at least part of the beta testing. A direct connection answers questions about the server and client combination. It does not establish how the intervening software handles the startup exchange. The project's explanation explicitly identifies both compatible servers and proxies as possible sources of a grease error.

I would preserve the complete error message and identify which component handled the connection before changing the test setup. The wiki asks users to contact the relevant software maintainers and report the issue to pgsql-hackers with a [grease] subject tag. It also asks for a link to a public upstream report when one exists. That provides a concrete route for a compatibility finding to reach both projects.

After reporting the problem, users can continue testing by adding the documented connection parameter below to their existing connection string.

max_protocol_version=3.0

The wiki also documents the equivalent PGMAXPROTOCOLVERSION environment variable. I would keep either workaround specific to the affected test and record why it was added. The project tells testers to remove it after the beta period. Leaving the workaround unexplained would make it harder to tell later whether negotiation was corrected or simply avoided.

For a proxy maintainer, the useful test is the response to an unsupported requested minor version or extension. The wiki says no protocol extensions have been defined as of 2026, so an unknown extension request should be reported back as unsupported. That is a negotiation requirement, not an instruction to implement a feature whose meaning the server does not know.

Feature testing still needs ordinary workloads

The first beta has a much broader scope than protocol checking. Its announcement describes automatic I/O worker scaling and parallel autovacuum, among other planned improvements. It also previews changes to logical replication and observability. I would choose tests based on the operations an application depends on, keeping the connection path intact wherever possible.

The beta testing guidance says prereleases are for testing and advises against production use. It also warns that behavior and interfaces can change incompatibly during beta development, and that features can be removed. A successful test is therefore evidence about this beta version. It does not turn every preview into a dependency that an application can assume will be present in the final release.

For me, an effective test report would identify the beta version and retain the smallest reproduction that still includes the failing component. If a proxy is involved, removing it may help diagnosis, but I would keep the original failing path documented too. That gives maintainers the evidence needed to distinguish a server regression from a negotiation implementation that ordinary connections had not previously exercised.