Before You Add a Vector Database, Test What Postgres Search Already Solves

A vector database is useful when you genuinely need vector search at a scale or operational shape your existing database cannot handle. But for many small and medium AI products, adding a separate retrieval system before measuring the search problem creates an extra service, an extra sync path, and an extra failure mode before it creates better results.

If your application already stores its source data in PostgreSQL, a stronger default is usually:

start with PostgreSQL full-text search, measure the queries it misses, add pgvector for semantic retrieval where that improves recall, then combine lexical and semantic results if the evaluation says hybrid search is better.

That is not an argument that dedicated vector databases are pointless. It is an argument for making the architecture earn its complexity.

Feature check — September 4, 2026: this article uses the current PostgreSQL 18 documentation and the current pgvector project documentation. Exact performance depends heavily on corpus size, query distribution, hardware, embedding model, filters, index settings, and latency targets, so the decision should be benchmarked on your own workload.

Search is four problems, not one

Teams often jump from “we need better search” to “we need embeddings.” Those are not the same requirement.

A useful retrieval system has to solve at least four different problems:

A vector index only directly addresses part of that picture.

For a support knowledge base, for example, the query “invoice PDF download” may be better served by lexical matching because product terms matter. The query “how do I get a copy of what I was charged for?” may benefit more from semantic retrieval because the wording can differ dramatically from the article.

The right architecture may therefore be both—not one search technology replacing the other.

What PostgreSQL full-text search already gives you

PostgreSQL's full-text search is much more than LIKE '%word%'.

The current PostgreSQL documentation describes a pipeline that parses text into tokens, normalizes words into lexemes, can remove stop words, can use stemming or dictionaries, stores a searchable tsvector, accepts structured tsquery queries, and can rank matching documents by relevance. It also supports boolean operators and phrase matching.

For a product that already runs on PostgreSQL, that means the first useful search baseline can live beside the data it searches.

A simple pattern looks like this:

ALTER TABLE articles
ADD COLUMN search_document tsvector
GENERATED ALWAYS AS (
  setweight(to_tsvector('english', coalesce(title, '')), 'A') ||
  setweight(to_tsvector('english', coalesce(body, '')), 'B')
) STORED;

CREATE INDEX articles_search_document_gin
ON articles USING GIN (search_document);

Then a query can use PostgreSQL's text-search operators and ranking:

SELECT
  id,
  title,
  ts_rank_cd(search_document, q) AS rank
FROM articles,
     websearch_to_tsquery('english', $1) AS q
WHERE search_document @@ q
ORDER BY rank DESC
LIMIT 20;

PostgreSQL supports GIN and GiST indexes for full-text search; its current documentation says GIN is the preferred text-search index type for the normal case.

This baseline has one architectural advantage that is easy to underestimate: your authorization and business filters remain normal SQL.

WHERE tenant_id = $2
  AND status = 'published'
  AND search_document @@ q

You are not copying records into another system and then trying to keep content, permissions, deletes, and metadata synchronized.

Where lexical search fails

Full-text search is not semantic understanding.

If a document says:

Change the email address associated with your account.

and a user asks:

How do I move my login to another email?

lexical retrieval may or may not rank the right document well, depending on the indexed language, dictionaries, synonyms, content, and query construction.

That is a real reason to test embeddings.

The important word is test.

Do not evaluate a retrieval architecture with five queries invented by the engineer who built it. Collect actual or representative searches and label which documents would be genuinely useful.

A small evaluation sheet can contain:

You do not need an impressive benchmark suite on day one. You need enough examples to discover which class of query is failing.

The next step can be pgvector, not another database

pgvector adds vector similarity search to PostgreSQL while keeping the vectors alongside relational data.

Its current documentation supports exact and approximate nearest-neighbor search and multiple distance functions, including cosine distance. By default, pgvector performs exact nearest-neighbor search; approximate HNSW and IVFFlat indexes can be added when the workload needs a different speed/recall trade-off.

A simplified schema can stay in the same table:

CREATE EXTENSION IF NOT EXISTS vector;

ALTER TABLE articles
ADD COLUMN embedding vector(1536);

The dimension here is only an example; it must match the embedding model you use.

A cosine-distance query can then look like:

SELECT id, title
FROM articles
WHERE tenant_id = $2
  AND status = 'published'
ORDER BY embedding <=> $1
LIMIT 20;

That gives you a useful intermediate architecture:

PostgreSQL
├── source content
├── permissions / tenant metadata
├── full-text index
└── embeddings via pgvector

For a small product, keeping those concerns together can be materially simpler than introducing a separate retrieval database immediately.

Exact search first, approximate search when the measurements demand it

Another easy mistake is assuming that “vector search” automatically means “ANN index.”

pgvector's current default is exact nearest-neighbor search. Approximate indexes are an optimization that trade some recall for speed.

That suggests a useful progression:

1. Get retrieval quality right with exact search.
2. Measure latency on the real corpus and real filters.
3. Add HNSW or IVFFlat only when exact search is the bottleneck.
4. Measure recall again after the index change.

pgvector's own documentation recommends monitoring approximate-search recall by comparing it with exact-search results.

HNSW is not a free speed button either. pgvector documents better query speed/recall trade-offs than IVFFlat, but slower index builds and higher memory use. Its ef_search and construction settings also change the speed/recall trade-off.

That is exactly why the architecture should follow the measurements rather than the acronym.

Hybrid search is often the useful destination

Semantic search is good at meaning. Lexical search is good at exact language.

Product search frequently needs both.

Think about these queries:

• ERR_CONNECTION_RESET
• GPT-6 Astra
• VAT invoice
• how can I stop being billed next month?
• customer cannot see my screen after navigating

The first three contain language you may want to match almost literally. The last two are natural paraphrases where semantic retrieval may help.

pgvector's documentation explicitly shows using vector search together with PostgreSQL full-text search for hybrid search, with Reciprocal Rank Fusion or a cross-encoder suggested as ways to combine the result lists.

You do not need to begin with a complicated learned ranker. A straightforward architecture is:

query
  ├── full-text retrieval ─────┐
  └── vector retrieval ────────┤
                               ↓
                         rank fusion
                               ↓
                       optional reranker
                               ↓
                          final top N

The important part is that the two retrievers fail differently.

A lexical result can rescue an exact product name that embeddings underweight. A semantic result can rescue a paraphrase that contains none of the article's important nouns.

Use a failure-driven migration ladder

Instead of selecting infrastructure by trend, use a sequence where each new layer fixes a demonstrated problem.

Stage 1: PostgreSQL full-text search

Start here when:

• the product already uses PostgreSQL;
• most searches are names, phrases, keywords, titles, documentation, support text, or error messages;
• tenant/permission filters matter;
• operational simplicity matters more than theoretical maximum scale.

Measure search quality and latency.

Stage 2: Add embeddings with pgvector

Add semantic retrieval when your evaluation shows repeated failures on paraphrases, concept matching, natural-language questions, or similarity tasks.

Do not delete full-text search just because embeddings have arrived.

Stage 3: Fuse lexical and semantic results

Use hybrid retrieval when each method wins on a meaningful subset of queries.

Measure top-k usefulness before and after fusion. If reranking is added, measure the extra latency and model cost too.

Stage 4: Tune approximate indexing

Move from exact vector search to HNSW or IVFFlat when vector latency or throughput becomes a demonstrated bottleneck.

Retest recall after the change, especially when filters are involved. pgvector notes that with approximate indexes filtering occurs after the index scan, which can affect how many qualifying results are returned; its iterative-scan features exist partly to address this problem.

Stage 5: Consider dedicated vector infrastructure

A separate vector system becomes much easier to justify when the retrieval workload itself has become an independently demanding service.

Examples include:

• the vector corpus or query throughput needs to scale independently from the primary database;
• index memory/build characteristics are becoming uncomfortable for the Postgres workload;
• retrieval requires capabilities or operational controls your current Postgres stack does not provide well;
• multiple products need a shared retrieval platform;
• the search team needs a separate scaling, deployment, or ownership boundary;
• measured latency or availability targets cannot be met cleanly inside the existing architecture.

At that point, an extra service is solving a real operational problem rather than merely matching an architecture diagram from an AI tutorial.

The hidden cost is synchronization

Suppose your canonical article lives in PostgreSQL but its searchable copy lives elsewhere.

Now every mutation creates questions:

• Was the vector record inserted after the source row?
• Did an edit update the text and embedding?
• Did deletion remove the external copy?
• Did a permission change propagate before the next query?
• What happens if the embedding API succeeds but the vector-database write fails?
• What happens if the database transaction commits but the queue worker dies?
• Can you rebuild the index deterministically?

These are solvable engineering problems. Event streams, queues, outboxes, retries, idempotency, reconciliation jobs, and rebuild pipelines all exist for good reasons.

But if your current workload does not need a second datastore, you are paying that complexity before you receive its benefit.

That is the strongest reason to start with the database you already operate—not because PostgreSQL is magically optimal for every retrieval workload, but because one source of truth is operationally cheap.

A practical weekend experiment

If you have an AI app with a few thousand or a few hundred thousand pieces of searchable content, you can learn more from one focused experiment than from a week of architecture debates.

Build four retrieval modes against the same evaluation set:

A. Full-text only
Use tsvector, a GIN index, and a sensible query function.

B. Vector only
Generate embeddings, store them in pgvector, and begin with exact search if the corpus permits.

C. Hybrid
Take candidates from both systems and combine their ranks.

D. Hybrid + reranking
Only if C still produces ranking problems worth the additional cost and latency.

Record:

• whether a useful document appears in the top few results;
• latency;
• filter correctness;
• failure type;
• operational work required to keep the index fresh.

Then choose the simplest mode that passes the product's actual requirements.

The experiment may tell you to stay with full-text search. It may tell you embeddings are a huge improvement. It may tell you hybrid is clearly best. Any of those is a useful result because the choice is now grounded in your workload.

When I would skip straight to dedicated vector infrastructure

The staged approach is not a rule that every team must start tiny.

If you already know you are ingesting a very large vector corpus, require independently scalable high-throughput similarity search, have a platform team that operates retrieval infrastructure, or depend on specialized capabilities your existing database cannot provide, starting with a dedicated system can be entirely reasonable.

Likewise, if the product's core asset is the retrieval layer, optimizing that layer early may be worth more than minimizing services.

The contrarian mistake would be replacing “always use a vector database” with “never use a vector database.”

The better rule is:

Use the smallest retrieval architecture that meets measured quality, latency, filtering, and operational requirements—and add another system when a specific requirement forces the move.

Conclusion

PostgreSQL already gives applications a serious lexical-search engine with normalization, ranking, phrase queries, and index support. pgvector can then add exact or approximate semantic similarity without immediately moving the source data into another service. The pgvector project even documents combining its vector results with PostgreSQL full-text search for hybrid retrieval.

That makes a useful default architecture for many AI products:

FTS → measure → pgvector → hybrid → approximate indexing → dedicated vector service if the workload proves it needs one.

The point is not to avoid new infrastructure. It is to make every new layer fix a problem you have actually observed.

Sources

Checked September 4, 2026:

• PostgreSQL 18 Documentation — Full Text Search introduction
• PostgreSQL 18 Documentation — Preferred index types for text search
• pgvector — Open-source vector similarity search for PostgreSQL