postgres-firstlisted

# PostgreSQL-First Architecture Use PostgreSQL first **only when measured requirements show it is sufficient**. This skill is an evidence gate, not a mandate to replace every specialized system. ## Non-negotiable rule Before adding, removing, or replacing a data service, collect evidence for: 1. **Performance** — expected peak throughput, p95/p99 latency, data size, query shape, growth margin. 2. **Semantics** — ordering, replay, fan-out, durability, delivery guarantees, consistency and availability needs. 3. **Operations** — blast radius, restore objectives, team skill, regional/compliance constraints, cost and failure isolation. If these are unknown, classify the decision as `NOT_PROVEN`; do not claim that PostgreSQL is sufficient. ## Decision workflow ### 1. Identify the workload Classify the requirement before choosing infrastructure: | Workload | PostgreSQL-native candidate | Keep/split a specialist when… | |---|---|---| | Flexible documents | `JSONB` + GIN | access patterns or scale are proven unsuitable | | Durable work queue | row table + `FOR UPDATE SKIP LOCKED` | broker semantics, partition isolation, replay/fan-out or throughput require it | | Cache | ordinary/unlogged tables, materialized views | latency or independent failure isolation requires an external cache | | Full-text/fuzzy search | `tsvector`, GIN, `pg_trgm` | relevance, indexing scale or search features exceed measured targets | | Vector retrieval | `pgvector` | measured recall/latency/cost jus