v0.1 draft — feedback, review, and open questions welcome

[arkstack-dev]

The first public draft of pg-quic is in docs/SPEC.md.
It specifies a binding of the PostgreSQL v3 wire protocol onto QUIC (RFC 9000) as transport.
No HTTP/3, no fork of v3 messages, no PostgreSQL server patch.

This thread is the entry point for review. If you have a comment that fits in one paragraph and doesn't fit an existing focused thread, post it here. For deeper discussion on specific sections, see the focused threads listed at the bottom.

What v0.1 covers

• Stream model: one QUIC bidirectional stream = one PG session (§3)
• Framing: v3 messages on the stream, no extra framing (§4)
• TLS + ALPN: pgsql/3, no SSLRequest, no 0-RTT in v0.1 (§5)
• Authentication: v3 SASL unchanged, channel binding bound to end-entity cert (§6)
• Cancellation: STOP_SENDING with PG_CANCEL, no BackendKeyData (§7)
• Connection migration: RFC 9000 §9, no binding-specific behaviour (§8)

What v0.1 deliberately does not cover

• Reference implementation. Spec-only at this stage.
• Interop test vectors. Listed as Appendix A open question 2.
• Unidirectional streams. Reserved, may be defined in v0.2 (likely for
  NOTIFY payload delivery).
• 0-RTT for any operation. Forbidden in v0.1; future revisions may relax
  for narrowly scoped idempotent cases.

What I most want feedback on

In rough order:

1. Channel binding (§6.1). Bound to the QUIC TLS 1.3 end-entity
   certificate. I want to know if any existing SCRAM-SHA-256-PLUS client
   implementation would have trouble obtaining that certificate from a
   QUIC stack's API surface (vs. a classical TLS stack). If so, that's a
   portability problem worth flagging in the spec.

2. Cancellation race (§7). Server treats STOP_SENDING with
   PG_CANCEL as a no-op if no query is running. This resolves the race
   between query completion and cancel arrival without any feedback
   mechanism. I think this is strictly better than the current CancelRequest
   behaviour, but I want to hear from people who have written cancel logic
   in real drivers whether anything subtle breaks.

3. Stream policy (§§3.3, 3.4). Servers MUST NOT open bidirectional
   streams; unidirectional streams reserved. Is there a use case I'm
   foreclosing prematurely?

4. 0-RTT rationale (§5.3). The rationale I give is resource exhaustion
   against authentication state allocation, not classical replay (SCRAM
   handles that). I want a sanity check from people who have implemented
   0-RTT in other protocols on whether that framing is correct.

5. Anything I missed. Especially: interactions with poolers
   (PgBouncer, pgcat), drivers (libpq, JDBC, psycopg, asyncpg, pgx),
   and load balancers that today rely on BackendKeyData routing for
   cancellation.

Scope of this project

The README states this, but worth restating here: pg-quic is intended as a vendor-neutral specification, governed independently. It is not a module of, or productization path for, any commercial driver or database product. The reason I'm flagging this up front is that I'm an active contributor in the JVM runtime space under a separate brand (Arkstack / Exeris), and I want it to be clear that this spec is not a vehicle for that work. If the spec gains traction, I'm open to moving it to a neutral org (e.g., a dedicated GitHub org with multiple maintainers) - the current location is a starting point, not a destination.

I'd welcome co-editors. If you're interested in long-term involvement, reply here or open an issue.

Focused threads

To keep this thread scannable, deeper discussion on specific topics should go in dedicated threads:

• Channel binding interop across QUIC stacks (§6.1) #3
• Cancellation semantics and pooler interaction (§7) #4
• 0-RTT scope for future revisions (§5.3) #5
• Reference implementation: language, scope, governance #6
• Stream policy #7

If your topic doesn't fit any of these, open a new discussion under the appropriate category rather than nesting deeply here.

What I'm not looking for in this thread

• "Why not HTTP/3?" - §1.5 covers it.
• "Why not patch PostgreSQL directly?" - §9 covers it (proxy is enough).
• General QUIC-vs-TCP debate - out of scope; this spec assumes QUIC is
  worth using and focuses on the binding.

Thanks for reading. Substantive review is more valuable to me than encouragement, so don't pull punches.