Production database query preflight

Read-only probes verified the production Neon topology and executed bounded recommendation queries against its actual catalog. This is query-cost evidence, not a production concurrency ceiling or recommendation-quality result. No deployment, feature flag, Redis configuration or database row was changed.

Topology and baseline

The configured primary and replica use distinct pooled endpoints. Both probes used one connection and a read-only transaction, a two-second statement limit, 250 ms lock limit and bounded connection/idle timeouts. PostgreSQL reported version 17.11 and max_connections=3604. The snapshot saw 32 primary and 16 replica backends, with no ungranted database locks in that observation. These counts are not app-pool queue measurements or evidence of peak headroom.

The replica's statistics estimate zero rows for the newly installed known-story ledger, but an exact read found 164,707 keys and 18,872 worlds. Replica statistics age must not be mistaken for missing replicated data. The exact Discover event count remains zero while canonical collection is disabled.

The existing shared Railway Redis reported 194,336,288 bytes used, 509,053,640 bytes historical peak, noeviction, maxmemory=0, six clients and 236 instantaneous operations/second. This is one observation, not peak traffic or a container memory limit. It does not justify allocating new Discover session capacity in the shared service. A dedicated Discover Redis and measured admission limits remain the rollout configuration.

Actual query builders

An isolated offline process invoked the candidate's existing recommendation builders with a fake empty-result database. It captured safe guest queries for English, Chinese, Japanese and Spanish: eleven initial cold-start/fallback statements plus catalog, selection and delivery per language, 56 total. The empty-result driver adds fallback queries that a nonempty live request may omit. Selection/delivery bound a synthetic missing ID; their plans do not measure populated hydration. SQL and source hashes were fixed before connection. No application providers, production credentials or remote services were used by the capture process.

All 56 queries successfully planned on the production replica. The four highest estimated-cost recall statements, with original index as tie-breaker, then ran serially with EXPLAIN (ANALYZE, BUFFERS, TIMING OFF). PostgreSQL execution times were 21.116 ms EN, 21.145 ms ZH, 25.819 ms ES and 21.006 ms JA. The result contains plan counters only, never story rows or vectors. Estimated planner cost is not elapsed time. Each selected query ran once; warm caches, planner estimates and shared workload affect these observations.

A separately frozen probe captured the actual signed-in safe English filters, including family-wide Library/favorite/review/dismissal exclusions. It used an empty taste profile and three nonempty-Library cohorts selected by ascending size and stable identity tie-break: middle, 95th percentile and maximum. Account identities stayed in memory and are absent from the saved results. This examines exclusion cost, not personalized profile construction or preferences.

Library entries	Newest recall, database ms	Popular recall, database ms	Catalog scan, database ms
1	120.404	43.401	22.155
14	25.120	48.431	21.760
428	99.864	91.813	83.502

All nine executions passed without timeout. The largest-library queries were more expensive than the 14-entry sample; the first one-entry query was also slower and read previously uncached blocks. This fixed-order, single-observation probe cannot isolate the causal effect of Library size or establish latency percentiles. It provides no reason to increase database pools or buy a new database service. Repeated language-family and sibling-counter subqueries remain visible in the plans and are candidates for a separately measured optimization.

Remaining release boundary

Cursor, measurement, semantic-personalization, onboarding and analytics-Discover readiness variables remain unset; their code defaults keep them off. There is no dedicated Discover Redis override. The production ClickPipe was again Running with seventeen mappings, still excluding discovery_events and discovery_erased_actors. No replication/erasure completion is inferred from other tables' health.

These observations complement the 73-check deployed functional validation. They do not cover app checkout queues, full personalized first-page fan-out, real traffic peaks, proxy/replica routing, background workloads or controlled production rollback. Those and canonical CDC/erasure receipts remain rollout gates; experimental ranker quality remains a separate unpassed gate.

Artifact SHA-256 values (ignored local files; no account identities persisted):

• Metadata observation: 4ecd7bbfb554de623f39688317a5e8cbd5f83dd835b04a5f73e59988f377f380.
• Guest query capture: 9b52259f372a7b96d775ed0b2b48b7c8596e17081ef8284b4f03d091110ca2f8.
• Guest plans/executions and actual flag-name check: 40ecb78698a27666f788d2d2ab7b96ddb94c504f6d332880a3e945daae6ea0d1.
• Account query capture: 462fefd2d636e2758ac25929ee67e2855b73edd92a429706b2c4c9589d0b2d47.
• Account executions: 8f6c2fa335acdb9556e21c69c3f9aba107fa93fcaed9d2f19ef15c51128cb50c.

The first metadata helper included unused PERSONALIZATION_* variable names. The subsequent guest-plan result checks the actual DISCOVERY_PERSONALIZATION_* and DISCOVERY_INTEREST_ONBOARDING_ENABLED names plus worker readiness. Claims about disabled features use the corrected check, not absence of unused names.