Neon

PASS consensus from 3 PASS.

Onboarding creates the project; the psql guide then covers installation, connection-string copying, connection, and two runnable queries. The signup tour walks sign-up to project to SQL Editor with a pre-filled sample table, and the connect page supplies a copyable connection string plus psql, pg, and psycopg2 snippets, so the path is unambiguous end to end. Three clear paths exist: Console SQL Editor with sample SQL, psql via connection string from the Connect button, or Neon CLI. All paths start from sign-up at console.neon.tech and are documented end-to-end.

PASS consensus from 2 PASS, 1 PARTIAL.

All six requested limits are stated, but pricing.md computes the same branch-hours as $0.02 while the plans page says about $0.20. All six categories carry a value and an explicit scope (projects 100/100/1,000; branches 10/10/25 per project with a 5,000 per-project cap on paid plans; compute 100 CU-hours per project on Free; storage 0.5 GB per project on Free; history 6 hours/7 days/30 days; public network transfer 5 GB per month on Free and 500 GB per project per month on paid), and the pricing page repeats the same numbers. Plan comparison table gives exact per-plan values for all required categories with consistent scoping (per-project or per-organization).

PASS consensus from 3 PASS.

The page maps named credential, SNI, pooling, cold-start, and capacity errors to explicit corrections. One page indexes 17 named connection errors and covers every axis the task asks for: credentials, four separate SNI workarounds, PgBouncer startup-parameter and search_path failures on pooled strings, scale-to-zero cold start, and both the active-endpoint and max_connections capacity limits. 17 documented error scenarios covering credentials, SNI, pooled connections, cold start, capacity, and more, each with specific diagnosis and documented fix.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The reference covers configuration, payloads, and verification, but it never defines NEON_AUTH_URL; the linked walkthrough uses NEON_AUTH_BASE_URL. Configuration, headers, the double-base64url signing-input reconstruction, a working Node crypto.verify example, idempotency, and retry limits are all on one page, but the JWKS fetch reads process.env.NEON_AUTH_URL while the Auth quickstart defines the variable as NEON_AUTH_BASE_URL, so the base URL must be resolved by cross-referencing another page. Complete end-to-end process: Neon API to configure webhooks, event types documented, Ed25519 detached JWS verification with JWKS, double base64url encoding, and a runnable Node.js verification function.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

Installation and DATABASE_URL setup are clear, but the minimum HTTP query targets an unspecified table and cannot run unchanged. Install, configure, and the minimum neon() HTTP template query are all clear, but the page's DATABASE_URL carries no query parameters while every canonical connection page shows ?sslmode=require&channel_binding=require, and nothing on the serverless page explains that the HTTP transport makes those libpq parameters moot. Installation (npm install @neondatabase/serverless), DATABASE_URL from the Connect button, and a minimal HTTP query example are all on one page and agree with the connection guidance.