labkit/v2/postgres: Switch to database/sql interface via pgx stdlib adapter

Context

The postgres package in LabKit v2 currently exposes pgxpool directly as its public interface. This was identified as a critical gap in the Artifact Registry PoC assessment.

Problem

Exposing pgxpool directly:

  1. Limits tooling choices — Most Go database libraries (ORMs, query builders, migration tools) target database/sql. Tools like Bun require database/sql and cannot use LabKit's wrapper without losing automatic query tracing.
  2. Blocks Container Registry code reuse — The Container Registry's database load balancing (read/write splitting, replica routing, LSN-based sticking) is built on database/sql and cannot be reused without a rewrite.
  3. Requires adapter boilerplate — LabKit v2's two-phase lifecycle means the pool doesn't exist until app.Start is called. Every data access layer needs a lazy-resolution adapter (poolProxy pattern) to bridge the gap.

Proposed solution

Expose database/sql as the public interface, using pgx as the underlying driver via pgx/v5/stdlib. This addresses all three issues while retaining pgx's performance characteristics.

Tasks

  • Evaluate impact of switching to pgx/v5/stdlib — tracing, connection pool settings, pgx-specific features
  • Update postgres package to return *sql.DB instead of *pgxpool.Pool
  • Verify sqlc pgx-mode vs database/sql-mode compatibility
  • Update go-service-template to use the new interface
  • Document migration path for consumers of the current pgxpool API

References