Vector or relational database: start with the query

Exact records and similar content answer different questions

An order-status request needs a current record. A question phrased in the customer's own words may need a relevant passage from documentation. I would start a database discussion with that distinction.

The scenarios below are illustrative, not reports of specific client incidents or performance benchmarks.

Relational records for facts

Orders, invoices, inventory and payments have identifiers and relationships. A question about order 2026/0042 should retrieve that record from the responsible system. A semantically similar document cannot substitute for its current status.

Before changing an existing database, examine its data model, queries and indexes. Adding an AI assistant does not by itself justify migration.

Full-text search for words and phrases

Product names, identifiers and phrases can be suitable full-text queries. Evaluate language processing and ranking with actual user searches.

PostgreSQL provides its own text-search ranking functions. Its default ranking should not be equated with BM25: the PostgreSQL documentation describes ts_rank and ts_rank_cd.

Vectors for similarity

Embeddings represent content numerically so it can be compared with other content. This can help retrieve related passages when a question uses different wording.

Similarity does not prove accuracy or freshness. The embedding model, document preparation and retrieval method affect the outcome. pgvector supports both exact and approximate nearest-neighbour search; approximate indexes trade some recall for speed.

An illustrative support assistant

“How do I return an item?” may be answered from the relevant procedure. “Has my order shipped?” requires an authorised lookup of the current order.

Product search can combine keyword matching, semantic similarity and exact filters. A price ceiling or available size should remain a constraint on the result.

Evaluate before deployment

Build representative queries and expected answers. Measure relevance, freshness, latency and access control. Include questions whose answers are absent from the source material.

Record the embedding model and source document with the data. Test a new model or document-splitting strategy separately before switching production. Set update and deletion rules according to the content rather than one universal retention period.

PostgreSQL with pgvector or a separate service?

If you already operate PostgreSQL, testing vector retrieval there may simplify data management and links to existing records.

Assess a dedicated search service using measurements. There is no universal document count that demands migration. Vector dimensions, filters, concurrency, memory, latency and retrieval quality also matter.

Include backups, restoration, monitoring and team time in the cost comparison. A server bill alone is not the full cost of an operated system.

Three questions for your project

1. Do you need an exact record, a text match or similar content?
2. Which system owns the current information and who may access it?
3. What quality and latency must you achieve on your own data?

Discuss search over your data →