We Chose PostgreSQL Over Vector Databases. Here's Why.

When you build a platform that does retrieval-augmented generation — fetching relevant documents to include in AI prompts — everyone assumes you need a dedicated vector database. Pinecone. Weaviate. Qdrant. Chroma.

We looked at all of them. We chose PostgreSQL with pgvector instead. It's been one of our best architectural decisions, and I want to explain why.

The conventional wisdom goes like this: vector databases are purpose-built for similarity search over embeddings. They're faster, more scalable, and have more features for vector operations. PostgreSQL with pgvector is a hack that works for small scale but won't hold up.

The conventional wisdom is wrong for our use case. Here's why.

First, we're multi-tenant. Every customer's data is isolated. PostgreSQL's Row Level Security gives us tenant isolation at the database level — every query automatically filters to the current tenant. With a separate vector database, we'd need to implement tenant isolation ourselves: either a separate index per tenant (operationally complex) or metadata filtering on every query (slower than it sounds at scale).

Second, our data is relational and vectorized. A knowledge chunk has an embedding vector (for similarity search), but it also has a source document ID, a team ID, tags, metadata, a creation date, and a processing status. We need to join chunks with documents, filter by team, sort by date, and search by metadata — all in the same query. In PostgreSQL, this is a single query with a vector similarity clause and standard SQL filters. With a separate vector database, it's two queries (one for vectors, one for metadata) that need to be merged in application code.

Third, operational simplicity matters enormously at our stage. We run PostgreSQL for everything: users, teams, agents, runs, billing, audit logs, and now vectors. One database to back up. One database to monitor. One connection pool to manage. One migration system. Adding Pinecone means: another service to provision, another connection to manage, another thing that can go down at 3 AM, another set of credentials to rotate, another vendor's pricing to track.

Fourth, pgvector's performance is more than sufficient for our scale. We're not doing billion-vector nearest-neighbor search. A typical customer has 10,000-100,000 chunks. At that scale, pgvector with an HNSW index returns results in single-digit milliseconds. We'd need to be at millions of vectors per tenant before a dedicated vector database provides meaningful performance advantages.

Fifth, and this one is underappreciated: transactions. When a user uploads a document, we create the document record, generate chunks, create embeddings, and store everything in a single database transaction. If the embedding generation fails halfway through, the entire operation rolls back cleanly. With a separate vector database, you need to coordinate writes across two systems — and handle the case where PostgreSQL succeeds but Pinecone fails, leaving your data in an inconsistent state.

There are legitimate cases for dedicated vector databases. If you have billions of vectors, if you need sub-millisecond search latency, if your queries are pure vector similarity without relational joins, or if you're doing real-time vector index updates at very high throughput — a purpose-built solution makes sense.

For a multi-tenant SaaS platform where each tenant has thousands to hundreds of thousands of vectors, where every query combines vector similarity with relational filters, and where operational simplicity directly translates to faster shipping and fewer outages — PostgreSQL with pgvector is the right call.

We can always add a dedicated vector database later if we hit pgvector's limits. Extraction is straightforward because the embedding vectors and metadata are in well-structured tables. But right now, the complexity cost of an additional database outweighs the performance benefit we'd get from it.

Sometimes the boring technology choice is the right one.