2.2. Azure Database for PostgreSQL
💡 First Principle: PostgreSQL with pgvector collapses the RAG stack: the same engine that enforces relational integrity on your business data also stores and searches embeddings. One engine, one query language, one transaction boundary — a SQL JOIN away from combining "what the customer bought" with "what documents are semantically relevant." Fewer moving parts is itself an architectural feature.
Why care? Because AI-200 gives PostgreSQL more syllabus bullets than any other single service — five subsections' worth — and because "add vector search without adding a new database" is exactly the requirement enterprises state. Azure Database for PostgreSQL Flexible Server is the platform: managed, with built-in pooling, HA options, and the pgvector extension one command away.
The mental model for everything vector-related here comes from Section 1.1.2's ANN trade-off, made concrete: think of a library. An exact search reads every book to find the five most relevant — perfect recall, absurd latency. An index (HNSW, IVFFlat) is the card catalog: it sends you to the right shelves immediately, but a relevant book occasionally sits misfiled on an unvisited shelf. You're tuning how many shelves to check.
⚠️ Common Misconception: "pgvector index searches return the same results as exact searches, just faster." HNSW and IVFFlat are approximate — they can miss true nearest neighbors. Only a full sequential scan is exact. The exam expects you to know this is usually an acceptable trade — and when it isn't (small tables, compliance-critical retrieval), skipping the index is legitimate.
