An AI-native vector database stores numeric representations called embeddings and finds nearby records by distance. A dependable AI-native data system also preserves ordinary fields, relationships, permissions, versions, and transactions. pgvector adds vector types, distance operators, and exact or approximate nearest-neighbor indexes to PostgreSQL, letting semantic retrieval live beside relational truth.
A normal database can find sku = 'A-104' exactly. Full-text search can find documents containing “refund policy.” Users often ask with different words: “Can I return this after two weeks?” An embedding model maps the question and candidate passages into vectors whose geometry attempts to preserve useful meaning. Nearest-neighbor search then finds semantically related candidates.
Three components are easy to confuse:
PostgreSQL already provides transactions, constraints, joins, JSON, full-text search, row-level security, backups, replication, and a mature operational ecosystem. pgvector adds vector operations without requiring a separate data system. This is valuable when a product needs queries such as “find semantically similar approved chunks for this tenant, document state, product, language, and date.”
The advantage is not “one database is always simpler.” It is the ability to make vector writes and business-state changes transactionally consistent, reuse authorization rules, join rich metadata, and operate fewer moving parts when the workload fits.
The write path extracts content, normalizes it, splits it into addressable chunks, assigns permissions and provenance, embeds it, and commits derived records. The read path authenticates the caller, constructs server-owned filters, embeds or rewrites the query, retrieves and reranks candidates, assembles bounded context, calls a model or feature, validates citations, and observes the outcome.
Do not use embeddings for exact identifiers, money calculations, hard permission decisions, or facts a relational predicate answers more safely. Hybrid systems use exact, lexical, semantic, and learned ranking together.
Write a workload card: vector count, dimensions, growth, updates per second, query rate, latency objective, recall objective, filters, tenant isolation, region, recovery objectives, team skills, and budget. Compare systems with a representative dataset and query set. A demo using 1,000 unfiltered rows cannot justify a billion-vector multi-tenant design.
Act as an architecture reviewer. For my use case—[describe users, sources, update rate, query rate, filters, security, and latency]—separate requirements into relational truth, lexical retrieval, semantic retrieval, generation, and operations. Ask for missing numbers. Do not recommend a database until you have produced a workload card and three falsifiable acceptance tests.
Verification contract: Reject any recommendation that lacks measured scale, filter shape, recall target, recovery target, or an alternative architecture.