Agentic Data Engineering Resources

Resource

Vector Database Use Cases

See when a vector database makes sense, when pgvector is enough, and where vector search falls short for AI agents.

Pedro Lopez

Jun 24, 2026

Updated Nov 5, 2026

Summarize with AI:

Many teams treat a vector database as the default for AI workloads involving unstructured data, especially in retrieval-augmented generation (RAG) and semantic search pipelines. That default can add engineering work, operating cost, and retrieval complexity without better results.

In many sub-billion-vector use cases, pgvector on existing PostgreSQL infrastructure is a defensible default. Dedicated vector databases matter most when workloads need hybrid search, high write concurrency, fast retrieval at scale, or support for large and high-dimensional datasets.

For AI agents, vector search helps with episodic memory and retrieval, but cross-system business context requires more than similarity search alone.

TL;DR

Vector databases are commonly used for RAG, semantic search, recommendation engines, and multimodal search, and they are also used for agent knowledge access and related retrieval tasks.
Dedicated vector databases matter most when workloads need hybrid search, high write concurrency, fast retrieval at scale, or support for large and high-dimensional datasets.
In many sub-billion-vector use cases, pgvector on existing PostgreSQL infrastructure is a defensible default.
For AI agents operating across enterprise systems, vector search supports episodic memory and retrieval. Cross-system business context requires more than similarity search alone.

What Are the Most Common Vector Database Use Cases?

The most common use cases differ less by model type than by query pattern, write profile, and filtering requirements. That is the practical way to decide whether existing PostgreSQL infrastructure is enough or whether a dedicated vector database is justified.

Use Case	Primary Query Pattern	Data Type	Latency Sensitivity	When a Dedicated Vector DB Matters
RAG for LLMs	Semantic search over document chunks	Text embeddings	Medium (sub-second acceptable)	Corpus exceeds millions of chunks or requires hybrid search
AI agent memory	Write-heavy with per-session retrieval	Conversation/observation embeddings	High (within tool-call budget)	High concurrent sessions with cross-session semantic recall
Semantic search	User-facing similarity queries	Text, product descriptions	High (interactive UX)	Scale beyond what pgvector handles or need hybrid dense+sparse
Recommendation engines	Nearest-neighbor over user/item embeddings	User behavior, product features	Medium	Catalog exceeds millions of items with frequent updates
Anomaly detection	Outlier identification in embedding space	Transaction, log, sensor embeddings	Varies (batch vs. streaming)	Streaming workloads requiring continuous write + immediate query
Multimodal search	Cross-modal similarity (image to text, etc.)	Mixed (image, text, audio embeddings)	Medium	Multiple modalities in a shared vector space with filtering
Semantic caching	Similarity match against prior queries	Query embeddings	Very high (must beat LLM inference latency)	High query volume with repetitive semantic patterns
Content moderation	Similarity match against known-violation embeddings	Image, text, video embeddings	High (must process before content is served)	Scale requires very fast matching across large known-violation corpora
Training data deduplication	Near-duplicate detection across datasets	Document/image embeddings	Low (batch process)	Dataset size exceeds what brute-force comparison handles
Enterprise knowledge retrieval	Hybrid keyword + semantic search over internal docs	Document embeddings with metadata	Medium	Multiple document types requiring filtered, permissioned retrieval

RAG Retrieval Stays Simple Until Scale or Hybrid Search Changes the Tradeoff

The vector database indexes chunked documents as vector embeddings and returns the most semantically relevant chunks at query time to ground large language model (LLM) responses. pgvector on PostgreSQL is a viable option for many workloads, while dedicated vector databases matter more for very large-scale or ultra-fast retrieval needs. They also become more useful when hybrid search matters, because teams otherwise compose full-text and vector retrieval from separate PostgreSQL features.

AI Agent Memory Turns Vector Search Into a Write-Heavy Retrieval Problem

Agents operating across multiple sessions need to recall prior observations, tool outputs, and conversation context. Vector databases store interaction embeddings and retrieve semantically relevant history during future sessions. Agent memory differs from batch document retrieval because each session writes new memories while also reading old ones, so latency and namespace isolation become operational concerns.

Semantic Search Over Unstructured Data Depends on Recall-Latency Tuning

Product catalogs, documentation, and support knowledge bases benefit when users do not know the exact terms. User-facing applications often have interactive latency targets, so teams tune Approximate Nearest Neighbor (ANN) index parameters against recall accuracy. As datasets grow, that tradeoff gets sharper, and filters and hardware start to matter as much as the index itself.

Recommendation Systems Depend on Embedding Compatibility Across User and Item Updates

Recommendation systems maintain two embedding populations, users and items, on independent update schedules that are often managed by different teams. That requires coordination so user and item embeddings stay on compatible versions. In practice, index build time can set the minimum delay between model retraining and a fully refreshed live index.

Anomaly Detection Depends on Filtering the Right Comparison Set

Normal behavior is embedded as vectors, and outliers in embedding space signal anomalies. Retrieval identifies transactions whose distance from nearest normal neighbors exceeds a threshold instead of fetching supporting context. In finance, this is how an accounts payable fraud detection agent isolates transactions that deviate from a vendor's normal pattern. Metadata filtering matters because a transaction should be compared against the same user's historical behavior, not the entire corpus.

Multimodal Search Works Only if the Shared Embedding Space Holds Up

Images, text, audio, and video converted to embeddings in a shared vector space allow cross-modal retrieval. Even with unified models, a modality gap can persist, where text clusters with text and images with images even when describing the same concept. Teams that only need text-to-image search can instead convert non-text content to text descriptions before embedding.

Semantic Caching Reduces Repeated LLM Work Only in Narrow Patterns

Before sending a query to an LLM, check whether a semantically similar query has already been answered. If the similarity score exceeds a threshold, return the cached response. This pattern works for FAQ-style chatbots with repetitive query patterns, but in AI agent contexts similar queries can still require different responses based on current agent state.

Content Moderation at Scale Uses Embeddings as a Second Pass

Production content moderation often uses a two-layer architecture: deterministic matching for known violations and embedding-based classification for novel content. When exact matching misses, the embedding classifier pipeline generates embeddings and scores content across violation classes. The embedding model determines moderation quality, and some image-text models perform poorly on document-style visuals like charts and dense text in images.

Training Data Deduplication Favors Batch Methods Before Vector Search

Deduplication in production LLM training pipelines commonly starts with exact hashing, then near-duplicate methods, with some workflows adding semantic clustering or embedding-based matching for more quality-sensitive cases. This is a batch workload where write throughput and index build time matter more than query latency. That makes it a poor fit for infrastructure chosen purely around interactive search.

Permissioned Enterprise Retrieval Requires Access Control Outside the Vector Index

Internal document search across company knowledge bases must respect access controls. The core challenge is decoupling access control list (ACL) storage from the vector index, since re-indexing on every permission change is prohibitively expensive. Retrieval then enforces those permissions with ACL or permission metadata synchronized alongside the indexed content.

How Should You Evaluate Vector Database Requirements?

The most useful comparison is workload versus constraints, not vendor versus vendor. Teams should decide based on what the retrieval system must do in production, not on whether a database appears in benchmark charts.

Requirement to Test	Why It Matters	If It Stays Simple	If It Fails
Corpus size and growth	Determines index size, rebuild cost, and operational overhead	Start with pgvector on existing PostgreSQL infrastructure	Move to a dedicated vector database if scale makes retrieval or rebuilds too slow
Hybrid search needs	Many enterprise workloads need lexical and semantic retrieval together	Compose full-text search with pgvector in PostgreSQL	Use a dedicated vector database if native hybrid retrieval becomes a hard requirement
Write concurrency	Agent memory and streaming workloads write while serving queries	Keep the simpler stack if writes remain moderate	Move if concurrent writes materially hurt freshness or latency
Filtering and permissions	Metadata filters and ACL enforcement often dominate production complexity	Keep permissions outside the vector index and validate filtered retrieval early	Rework the architecture if permission checks or filters break recall or latency
Embedding dimensions	Dimensional limits can block model choice	Use pgvector when the embedding size fits the standard vector type or acceptable alternatives	Re-evaluate the storage layer when model dimensions exceed practical limits
Query latency under load	User-facing search and agent loops have different budgets	Benchmark on production-like filters and concurrency	Change infrastructure only if measured latency misses the budget

One benchmark or ranking is not enough to choose infrastructure. Run workload-specific benchmarks on your own data before making infrastructure decisions.

What Is the Best Way to Choose a Vector Database for Your Use Case?

The practical default is to start with the simplest stack that can satisfy the workload. For many teams, that means pgvector on existing PostgreSQL infrastructure first, then a move only if measured requirements force it.

Most workloads benefit from running these tests in order:

Start with corpus size, write rate, and latency budget.
Test recall and latency on production-like filters, not just clean benchmark datasets.
Validate permission handling early if the workload touches internal documents or customer data.
Check whether hybrid search is merely helpful or a hard requirement.
Confirm that embedding dimensions and model migration costs fit the storage design.
Move to a dedicated vector database only when those tests fail on the simpler stack.

Vector databases handle episodic recall of similar past events reasonably well, and they also support semantic memory retrieval. Structured state memory usually fits better in key-value, relational, or graph-backed stores. A vector store containing both "user prefers Python" and "user prefers JavaScript" returns both with similar relevance scores when either fact is queried, with no native staleness or contradiction detection. Working state retrieval often needs exact retrieval with strong transactional consistency, so it follows a different access pattern from approximate nearest neighbor search.

Production systems combine vector stores with key-value and graph stores to cover all three memory types.

Embedding Model Changes Propagate Through Every Retrieval Pattern

The vector database is only as good as its embeddings. Some embedding models may be deprecated or receive reduced support over time. Embedding model changes can make an index go stale because stored vectors were generated by a different model, and similarity scores are not comparable across versions. Model migrations can also require threshold retuning and substantial re-embedding work.

Cross-System Business Context Exceeds What Similarity Search Can Express

Acme Corp in Salesforce, acme-corp in Stripe, and Acme in Zendesk are the same company, but a vector database stores them as three separate records with no built-in way to assert they represent the same entity. Similarity retrieval also cannot traverse multi-hop queries across systems, such as correlating billing anomalies with support volume changes after renewals. AI agents need structured, unified business context across systems, and context engineering prepares that data for cross-system retrieval and reasoning. A stripe agent connector feeds billing records into that unified context, so the agent can correlate Stripe payment anomalies with the same company's CRM and support data.

For AI agents, the harder question is often not which vector database to pick, but which parts of context should live in vector search at all. Airbyte's agentic platform uses Context Store as a pre-materialized, search-optimized index of business systems where indexed business data becomes searchable across systems. In Airbyte's agentic platform, that data is exposed through the Web app, Agent MCP, Agent SDK, and API. That gives agents a searchable layer across systems for indexed business data without reducing the problem to similarity search alone.

Get a demo to see how Airbyte's agentic platform stores and exposes cross-system business data for production AI agents, or try Airbyte's agentic platform today.

Frequently Asked Questions

What is the most common vector database use case?

RAG for LLMs is a widespread use case. The vector database indexes document chunks as embeddings and retrieves the most semantically relevant chunks to ground LLM responses.

Do I need a dedicated vector database or can I use pgvector?

pgvector on PostgreSQL handles many use cases at sub-billion vector scale. Dedicated vector databases become more compelling for very large-scale workloads or dimensions above what the standard vector type supports. The decision should come from measured workload constraints, not default architecture preference.

How do vector databases work with AI agents?

They store past observations and conversation history as embeddings for semantic retrieval across sessions. That helps with episodic memory and related recall tasks. It does not replace exact state storage, permission logic, or cross-system entity resolution.

Can vector databases handle data from multiple enterprise systems?

They index embeddings from multiple sources as separate records rather than as unified cross-system entities. That means retrieval can find similar records across systems, but it does not inherently express business identity or multi-hop relationships.

What are the main trade-offs when using a vector database in production?

Recall accuracy and query latency move against each other, so approximate nearest neighbor indexes need careful parameter tuning. Embedding model dependency also means retrieval quality can change when the model changes, and re-embedding a large corpus can require substantial compute. In practice, filtering, permissions, and write patterns are often as important as raw nearest-neighbor speed.