Is pgvector production-ready?

For many workloads, yes — especially when you already run PostgreSQL. With proper indexing it handles typical business knowledge bases well. Very large or high-throughput workloads may benefit from a dedicated engine.

Do we need a vector database at all?

Not always. For small, stable knowledge, putting content directly in the prompt with caching can be simpler. See RAG vs fine-tuning vs prompting.

Comparison · Comparison

Choosing a vector store for RAG: start with what you already run.

The vector database is rarely what makes or breaks a RAG system — retrieval design is. But the wrong choice adds operational burden or blocks hybrid search and permission filtering. Here’s how the common options compare and how we choose.

By Nythrex EngineeringUpdated 24 September 2026 2 min read

Smaller collections → Very large collections

Managed services (Pinecone, Azure AI Search)

Qdrant / Milvus self-hosted

pgvector in managed Postgres

pgvector / OpenSearch you operate

Less to operate → More control

Rough positioning. Most business RAG systems live comfortably in the lower half.

Side by side

General characteristics; capabilities evolve quickly — check current documentation.
	pgvector (PostgreSQL)	Azure AI Search	Qdrant	Pinecone	Elasticsearch / OpenSearch
Type	Extension to your database	Managed search service	Open-source vector DB; managed cloud available	Managed vector DB	Search engine with vector support
Hybrid keyword + vector	Via Postgres full-text + vectors	Built in, with semantic ranking	Supported (sparse + dense)	Supported	Strong keyword search + vectors
Filtering for permissions	SQL — very flexible	Filters and security trimming patterns	Rich payload filtering	Metadata filtering	Rich query filters
Operations	Part of your DB	Managed by Azure	Self-host or managed	Fully managed	Self-host or managed
Sweet spot	Up to millions of chunks, apps already on Postgres	Azure-centric enterprises	Large collections, complex filters, self-hosting	Teams wanting zero ops	Teams already running Elastic/OpenSearch

How we choose

1
Reuse what you operate
Every new database is another thing to secure, back up and monitor. If an existing Postgres or search cluster can do the job, start there.
2
Require hybrid search
Exact terms — product codes, error IDs, names — are common in business questions. Pure vector search misses them.
3
Require filtering at query time
Permissions, tenants, document status and dates must be filters in the query, not post-processing.
4
Estimate scale honestly
Count chunks, not documents, and growth over two years. Most business knowledge bases are smaller than people expect.
5
Keep the index rebuildable
Store source documents and chunking logic so you can re-embed or switch stores without data loss.

Frequently asked questions

ServiceRAG developmentRAG development: AI assistants that answer from your documents and data with citations, permissions and measured accuracy — built in your cloud.GuideRAG vs fine-tuning vs promptingRAG adds knowledge, fine-tuning changes behaviour, prompting is where you start. How to choose — with a decision tree, costs and pitfalls.ComparisonOpenAI vs Azure OpenAI vs AnthropicChoosing an LLM platform: OpenAI, Azure OpenAI, Anthropic (direct, Bedrock, Vertex AI), Gemini and open-weight — by data, procurement and quality.GuideLLM evals for non-ML teamsHow to evaluate an LLM feature without a data-science team: build a test set, choose metrics, use LLM-as-judge carefully, run evals in CI and read the results.

Want a second opinion on your project?

Tell us what you’re building and where you’re stuck. We’ll reply within one business day with the most practical next step — even if that step isn’t us.

Start a project