Vector DB vs. Traditional DB

In this chapter

We'll meet vector storage and scaling at real volume, multi-tenancy and security, evaluation and the real distinction between hallucination and retrieval failure, and close on the honest, practical choice between pgvector and a dedicated vector database.

10–12 min

The Problem in Real Life

The shopping assistant works. Sarah now has one real, practical decision left: GreenMart already runs Postgres for its relational data. Does the vector search need its own, entirely separate database — or can Postgres just... also do this?

Mike wants a straight answer, not a philosophy lecture.

Do we need a whole new database, or can the one we already have just learn this trick?

Mike

A Dedicated Vector Database vs. Postgres Plus an Extension

Vector storage and scaling are real costs

384 numbers per document, millions of documents — the same distributed-systems scaling lessons, now applied to ANN indexes.

Hallucination vs. retrieval failure, precisely

A wrong AI answer needs a different fix depending on whether retrieval found the wrong documents or the model invented something ungrounded.

Evaluation means real testing, not eyeballing

Genuine recall/relevance testing against known-correct answers — not just checking that a few results look reasonable.

pgvector vs. a dedicated vector DB

The same recurring "what does the workload actually need" question this whole course keeps asking, now a concrete, real choice.

Three real, separate questions, the same pattern this course keeps returning to. What does storing and scaling millions of real vectors actually require? What does trusting a vector search system's answers actually take? And, practically, does GreenMart need a whole new database, or an extension to one it already runs?

On storage and scale. Vector storage is genuinely heavy — this course's own model produces 384 numbers per document; at 4 bytes each, that's roughly 1.5KB per vector before any index overhead, and a real catalog can mean millions of these. Scaling a vector system means the same distributed-systems lessons this whole course has built, now applied specifically to ANN indexes: sharding a large index across machines, keeping it fast as vectors keep getting added. Multi-tenancy is a real, practical concern once GreenMart isn't the only business using this system — many customers' data sharing one vector database safely, each one only ever able to search their own vectors, never another tenant's.
On trusting the answers. Security here means the same access-control question every database in this course has had its own version of: who's allowed to query or write which vectors. Evaluation is genuinely harder than it sounds — knowing a vector search system actually works well means testing it against a real set of queries with known correct answers, checking recall and relevance the same rigorous way, not just eyeballing a few results that happen to look reasonable. Hallucination vs. retrieval failure is a precise, valuable distinction for any RAG system: if an AI assistant gives a wrong answer, is it because retrieval found the wrong documents (a real, fixable retrieval failure), or because the model invented something ungrounded even from genuinely good documents (a hallucination)? These need different fixes — better retrieval for one, a more careful prompt or a more cautious model for the other — and conflating them means fixing the wrong problem.
On the actual, practical choice. A vector DB vs. traditional DB decision, honestly, isn't "vector databases are better" — it's the same trade-off this entire course keeps returning to: what does GreenMart actually need to ask, and which tool makes that cheap? PostgreSQL + pgvector — a real, genuinely popular Postgres extension — lets an existing relational database also store and search vectors, keeping everything in one system, one set of operational skills, one place for a query that needs both a relational JOIN and a similarity search together. A dedicated vector database (built specifically for this, at real production scale) usually wins once vector search is the primary workload, not a secondary feature — better ANN performance, better multi-tenancy support, purpose-built tooling. Neither is universally correct.

This closes the loop this Act's very first chapter opened with: real, verified similarity scores proved meaning-based search actually works. This chapter is the honest reminder that making it work in a demo and making it work safely, cheaply, and correctly at real production scale are two different, both real, jobs — and choosing pgvector versus a dedicated vector database is a genuine instance of the exact decision this entire course has been building toward making well.

Key Takeaway

There's no universally correct answer between a dedicated vector database and pgvector bolted onto Postgres — the same honest, recurring lesson this whole course has taught for every database it's covered. What matters is whether vector search is GreenMart's primary workload or a secondary feature next to data that's already relational — that answer decides the right tool, not a general reputation either technology has.

Why This Matters

This is the last real decision this Act leaves GreenMart with, and it's the same shape of decision this entire course has been building the judgment to make well — not which technology sounds newest, but which one actually fits the real workload.

GreenMart now has a real, working shopping assistant, an honest sense of what running it at real scale actually costs, and a genuine framework for choosing between pgvector and a dedicated vector database. The checkpoint ahead asks Sarah — or you — to wire up GreenMart's actual shopping assistant from scratch, with every one of this Act's lessons made on purpose.