Introduction

A vector database decision often begins as a performance question and ends as an architecture question. A team wants to add semantic search, retrieval-augmented generation, or an AI assistant. Embeddings must be stored somewhere. The obvious choices are to add vector capabilities to PostgreSQL with pgvector or to introduce a purpose-built vector database. Both approaches can work. The costly mistake is choosing based on category labels rather than workload evidence.

PostgreSQL with pgvector can keep embeddings beside users, documents, permissions, products, tickets, and other application records. That can simplify consistency, authorization, backup, and operations. Dedicated vector databases, however, are designed around vector retrieval as a first-class workload and may provide stronger scaling models, specialized filtering, multi-vector retrieval, hybrid search, isolation, and vector-specific operational controls. The right answer depends on what your application must guarantee, not on whether one product wins a synthetic benchmark.

This guide explains how to make the choice systematically. It focuses on architecture, retrieval quality, filtered search, hybrid search, scalability, latency, multitenancy, security, cost, observability, reliability, and migration. It does not include code. The goal is to help you decide what to deploy, what to benchmark, what to monitor, and what evidence should trigger a future change.

Table of Contents

1. The decision in one minute
2. Why vector storage architecture matters in 2026
3. Vector search concepts you need before choosing
4. What pgvector gives you inside PostgreSQL
5. What a dedicated vector database changes
6. pgvector vs dedicated vector database: comparison table
7. When pgvector is the better choice
8. When a dedicated vector database is the better choice
9. The ten decision criteria that matter most
10. Exact search, HNSW, and IVFFlat
11. Filtered search: the hidden production problem
12. Hybrid search and retrieval quality
13. RAG architecture patterns
14. Multitenancy and authorization
15. Security and data governance
16. Performance planning and benchmarking
17. Cost and operational complexity
18. Reliability, backup, and disaster recovery
19. Migration strategy and exit planning
20. Real-world decision scenarios
21. Common mistakes
22. Best-practice checklist
23. Troubleshooting a vector retrieval architecture
24. Frequently asked questions
25. Conclusion

1. The Decision in One Minute

Choose PostgreSQL with pgvector when vectors are an extension of an application that already depends on PostgreSQL. This is particularly compelling when vector results must be combined with relational facts, permissions, status fields, tenant identifiers, timestamps, or transactional updates. A single data platform can reduce synchronization work and make operational behavior easier to understand.

Choose a dedicated vector database when vector retrieval is becoming an independent platform workload. Signals include very large collections, high concurrent query volume, strict tail-latency objectives, complex metadata filtering at scale, advanced hybrid or multi-stage retrieval, large multi-tenant deployments, multimodal vector use, or a need to scale retrieval separately from transactional data.

Do not treat vector count alone as the decision. Ten million small vectors with simple unfiltered queries can be easier than one million large vectors with restrictive filters, high write rates, strict permissions, and aggressive latency targets. The workload shape matters more than a single number.

2. Why Vector Storage Architecture Matters in 2026

Vector retrieval is no longer limited to experimental chatbot prototypes. It now supports enterprise search, customer support, product discovery, recommendations, fraud investigation, security analytics, document intelligence, knowledge assistants, agent memory, and multimodal systems. As these applications move into production, the storage layer becomes a reliability and governance boundary rather than a simple embedding container.

PostgreSQL has become increasingly attractive because teams can extend an existing system instead of introducing another database. Datadog’s 2026 “State of Postgres” report identified pgvector as the fastest-growing non-bundled extension in its telemetry, with 24% growth from December 2025 to May 2026. That does not prove pgvector is universally best, but it is strong evidence that vector workloads are moving into mainstream PostgreSQL deployments. [1]

Meanwhile, dedicated vector systems continue to evolve. Qdrant documents hybrid and multi-stage queries plus payload filtering; Weaviate combines vector search with BM25 and configurable fusion; Pinecone supports dense, sparse, and full-text search patterns together with namespaces and metadata filtering; and Milvus supports multi-vector hybrid retrieval and reranking. The market is therefore not converging on one architecture. It is converging on a richer set of retrieval requirements. [3][4][5][6]

3. Vector Search Concepts You Need Before Choosing

3.1 Embeddings and Similarity Search

An embedding converts an item such as a text passage, image, product, or user behavior pattern into a numerical vector. Items with related meaning tend to occupy nearby regions of the embedding space. Vector search finds the stored items whose vectors are closest to a query vector according to a distance or similarity measure.

The storage decision matters because searching vectors efficiently is different from looking up an exact key. At small scale, exact nearest-neighbor search can compare the query against every candidate and return mathematically exact results. At larger scale, approximate nearest-neighbor indexes reduce the amount of work by trading a small amount of recall for much better speed.

3.2 Recall, Latency, and Throughput

Recall measures whether the retrieval system returns the neighbors that an exact search would have returned. Latency measures how long a query takes, while throughput measures how many queries the system can process over time. A production design must balance all three. A configuration that is extremely fast but frequently misses relevant documents can damage RAG answer quality even if infrastructure metrics look excellent.

Tail latency also matters. A median query can appear healthy while the slowest five or one percent of requests create noticeable user delays. Interactive search, conversational AI, and agent workflows often care more about predictable high-percentile latency than raw peak throughput.

3.3 Dense, Sparse, and Hybrid Retrieval

Dense vectors are strong at semantic similarity: they can connect paraphrases and concepts even when exact words differ. Sparse or lexical approaches are stronger when exact terminology matters, such as product identifiers, error codes, legal phrases, names, acronyms, and specialized technical terms. Hybrid retrieval combines semantic and lexical signals to reduce the weaknesses of either approach alone.

This is important for the database decision because different systems package hybrid search differently. Some provide a single native workflow, while PostgreSQL often combines vector retrieval with its existing text-search and ranking capabilities. The best architecture is the one that meets your relevance goals with acceptable complexity and observability.

4. What pgvector Gives You Inside PostgreSQL

pgvector is an open-source PostgreSQL extension that adds vector data types, similarity operations, exact nearest-neighbor search, and approximate vector indexes. Its official documentation supports both HNSW and IVFFlat indexes. HNSW generally offers a stronger speed-versus-recall trade-off at the cost of slower builds and greater memory use, while IVFFlat typically builds faster and uses less memory but requires more careful tuning and data-dependent training. [2]

The architectural advantage is not merely that PostgreSQL can store vectors. It is that vectors can live in the same transactional environment as the application data they describe. A document embedding can be associated with document status, tenant ownership, access policy, timestamps, product state, or workflow metadata without maintaining a second authoritative copy of those fields in another system.

That colocation can reduce failure modes. If application data and vector metadata live in separate systems, the team must decide how updates are synchronized, how deletions propagate, how permission changes become visible, how retries are handled, and what happens when one write succeeds while another fails. A single Postgres-centered architecture can make many of those questions simpler.

5. What a Dedicated Vector Database Changes

A dedicated vector database treats retrieval as its primary workload rather than as one capability inside a general-purpose relational engine. The system may be designed around distributed vector indexes, vector-specific filtering, sharding, replication, quantization, multi-vector objects, hybrid ranking, reranking, and independent scaling.

Qdrant, for example, documents payload indexes for filtered vector search and supports hybrid and multi-stage query patterns. Weaviate combines vector search with BM25 and configurable fusion. Pinecone offers serverless index patterns, namespaces for partitioning and multitenancy, metadata filtering, and several hybrid retrieval patterns. Milvus supports multiple vector fields and hybrid search with reranking. These capabilities are not identical, but they demonstrate why “dedicated vector database” is more than a storage label. [3][4][5][6]

The trade-off is operational expansion. A second data system requires provisioning, access control, monitoring, backup or recovery planning, data synchronization, incident ownership, cost controls, and a clear source-of-truth model. A specialized product earns that complexity when its capabilities materially improve the application or simplify a vector-heavy workload.

6. pgvector vs Dedicated Vector Database: Comparison Table

7. When pgvector Is the Better Choice

7.1 PostgreSQL Is Already Your System of Record

If the application already depends on PostgreSQL, adding pgvector can be the lowest-complexity architecture. The team keeps familiar backup, replication, security, monitoring, schema-management, and operational practices. This can be more valuable than winning a narrow vector benchmark, especially for a small team.

7.2 Retrieval Depends Heavily on Relational State

Many real RAG queries are not “find the nearest text.” They are “find the nearest approved documents that belong to this tenant, that this user can access, that are not archived, that match a product or language constraint, and that are still valid.” When those constraints already live in PostgreSQL, keeping retrieval close to relational state can reduce complexity and authorization drift.

7.3 You Want Fewer Distributed Consistency Problems

A two-database architecture needs a strategy for lag and partial failure. If a user loses access to a document, how quickly must that change disappear from vector retrieval? If a document is deleted, is the vector deleted immediately, asynchronously, or eventually? If synchronization fails, which system is authoritative? pgvector can eliminate some of these cross-system consistency questions by keeping the relevant records together.

7.4 Your Team Values Operational Simplicity

Infrastructure complexity has a real cost. Every new managed service or cluster needs authentication, authorization, logging, monitoring, alerting, network rules, backups, incident runbooks, cost oversight, vendor knowledge, and upgrades. If pgvector meets the workload, avoiding a new service can be a meaningful engineering advantage.

8. When a Dedicated Vector Database Is the Better Choice

8.1 Retrieval Must Scale Independently

A transactional database and a retrieval service can have different resource profiles. If vector queries consume enough CPU, memory, I/O, or cache to compete with business transactions, independent scaling becomes attractive. A dedicated vector tier can protect the system of record from retrieval spikes and let each workload use different hardware and scaling policies.

8.2 Filtered Recall or Tail Latency Becomes a Bottleneck

Approximate vector indexes interact with filters in ways that can surprise teams. pgvector’s documentation explains that filtering can reduce the number of usable results after an approximate index scan and provides iterative scans to search further when necessary. A vector-native engine with strong filter-aware indexing may be preferable when heavily filtered queries dominate and strict latency or recall targets must be maintained. [2][3]

8.3 You Need Specialized Retrieval Features

Dedicated platforms may be attractive when your retrieval architecture depends on multiple named vectors, dense-and-sparse fusion, multi-stage retrieval, reranking, multimodal search, specialized quantization, or vector-oriented tenant isolation. The decision should be tied to specific features your application uses, not a generic belief that a specialized database is automatically faster.

8.4 Your Vector Collection Is Becoming a Platform

If many applications, teams, or agents use one retrieval layer, the vector system may deserve its own lifecycle, service-level objectives, capacity planning, and ownership. At that point, a dedicated vector database can be easier to treat as a platform service than an extension attached to a transactional database owned by another team.

9. The Ten Decision Criteria That Matter Most

10. Exact Search, HNSW, and IVFFlat

10.1 Exact Search

Exact nearest-neighbor search examines enough of the data to guarantee the mathematically closest results. It provides perfect recall relative to the chosen distance metric but becomes more expensive as the collection, vector dimension, and query rate grow. Exact search remains useful as a quality baseline even when production uses approximate indexes, because teams need a reference for measuring recall.

10.2 HNSW

Hierarchical Navigable Small World indexing organizes vectors in a graph that can be traversed efficiently. pgvector’s documentation states that HNSW generally provides a better query speed-versus-recall trade-off than IVFFlat but has slower build times and uses more memory. HNSW is also widely used across vector databases, although implementation details and tuning behavior vary. [2]

10.3 IVFFlat

IVFFlat groups vectors into lists and searches a subset of those lists. pgvector describes it as faster to build and lighter on memory than HNSW, but usually weaker in query performance for a given recall target. Its quality depends on how the lists are created and how many are searched. This makes it important to benchmark after the dataset has reached a representative size. [2]

10.4 Why Index Choice Does Not Settle the Database Choice

Two products can both support HNSW and still behave differently because of storage layout, filter integration, caching, sharding, replication, concurrency control, quantization, maintenance behavior, and distributed execution. “Supports HNSW” is therefore a starting fact, not a complete performance comparison.

11. Filtered Search: The Hidden Production Problem

Production retrieval almost always includes filters. A user may only be allowed to search one tenant, one department, one language, one product family, one time range, or one document status. Those filters can dramatically change vector-search behavior because the nearest candidates in the full vector space may not belong to the allowed subset.

pgvector’s documentation explicitly warns that filtering with approximate indexes can reduce returned results because filtering may be applied after candidate scanning. It offers iterative index scans that can continue searching to improve results under filters. It also recommends conventional relational indexes, partial indexes, or partitioning depending on filter patterns. [2]

Qdrant describes payload indexes intended to make filtered retrieval efficient. This illustrates a broader distinction: a dedicated vector database may integrate metadata filtering more deeply into its retrieval engine, while PostgreSQL can combine vector retrieval with a mature relational optimizer and indexing system. Neither approach should be assumed superior for every filter. The only safe conclusion is to benchmark the exact filter distributions your application uses. [3]

12. Hybrid Search and Retrieval Quality

Semantic similarity is excellent for conceptual matching, but it can miss exact terminology. Keyword retrieval is precise for names, codes, acronyms, and rare terms, but it can miss paraphrases. Hybrid search combines both signals, which is especially valuable in technical documentation, ecommerce catalogs, legal content, enterprise knowledge bases, and support systems.

Dedicated platforms increasingly treat hybrid search as a core capability. Weaviate combines vector search and BM25, then fuses the result scores. Qdrant supports dense and sparse retrieval with fusion methods such as reciprocal rank fusion. Pinecone documents multiple dense-plus-sparse and full-text patterns. Milvus supports multi-vector hybrid search and reranking. [3][4][5][6]

PostgreSQL can also support hybrid retrieval by combining vector similarity with lexical capabilities and relational signals. The architectural question is whether your team prefers to compose those components in a familiar database or use a product where hybrid retrieval is packaged as a first-class workflow. Evaluate the result quality, explainability, tuning complexity, latency, and operational cost together.

13. RAG Architecture Patterns

13.1 Postgres-First Architecture

In a Postgres-first design, documents, metadata, permissions, chunk records, and embeddings live in the same database. Retrieval uses pgvector alongside relational filters. This pattern minimizes synchronization and is often ideal for SaaS products that already rely heavily on PostgreSQL.

The main risk is resource contention. If vector indexes become large or retrieval traffic grows rapidly, the same database may be responsible for transactions, reporting, maintenance, and vector search. Capacity planning should therefore include realistic vector growth and concurrency from the beginning.

13.2 Split-Store Architecture

In a split-store design, PostgreSQL remains the source of truth for application records while a dedicated vector database stores embeddings and selected metadata for retrieval. A synchronization process propagates creates, updates, deletes, permission changes, and re-embedding events.

This pattern allows independent scaling, but consistency becomes a design concern. Teams should define the acceptable synchronization delay, how failures are retried, how stale vectors are detected, and what happens when the vector store contains a document that PostgreSQL no longer authorizes.

13.3 Vector-First Platform Architecture

A vector-first architecture treats retrieval as a shared platform. Multiple applications or agents use a dedicated vector service, while operational data remains elsewhere. This can be appropriate for organizations with large shared knowledge collections, multimodal search, or high query volumes across many products.

The platform team must then establish ingestion contracts, tenant boundaries, schema conventions, embedding lifecycle rules, observability standards, quality benchmarks, and service-level objectives. The vector database is no longer an implementation detail; it becomes infrastructure.

14. Multitenancy and Authorization

A secure retrieval system must enforce the same access rules as the application. This becomes more difficult when vector data is copied into a separate service. It is not enough to store tenant identifiers as metadata if the query path can accidentally omit the filter or if stale permissions remain searchable.

PostgreSQL can be attractive when authorization data already lives relationally and the retrieval query can be constrained by the same source of truth. Dedicated vector systems may offer tenant-oriented mechanisms such as namespaces, collections, partitions, or payload filters. Pinecone, for example, documents namespaces as a mechanism for partitioning records and supporting multitenancy. [5]

Whichever architecture you choose, define tenant isolation as a security property, not only a performance strategy. Test negative cases deliberately: a user from one tenant should not be able to retrieve another tenant’s content even when vectors are highly similar.

15. Security and Data Governance

15.1 Protect Embeddings and Source Content

Embeddings are not a substitute for data classification. They may encode information derived from confidential text, customer records, internal documents, or regulated content. Treat vector storage as part of the sensitive-data boundary. Apply network controls, least-privilege access, encryption, audit logging, and retention rules that match the source material.

15.2 Prevent Authorization Drift

A split-store architecture can create authorization drift if metadata or permissions are stale. Deletion and revocation paths deserve the same engineering attention as ingestion. If a document is removed from the source system, the team should know exactly when it becomes unreachable through vector search and how that behavior is verified.

15.3 Manage Embedding and Re-Embedding Lifecycles

Changing an embedding model can require reprocessing an entire corpus. During migration, old and new vectors may coexist. Plan versioning, rollback, quality comparison, storage overhead, and consistency between indexes. A database choice that is cheap for steady-state queries may become expensive during a full re-embedding event.

15.4 Treat Retrieval Logs as Sensitive

Search queries and retrieved document identifiers can reveal user intent and confidential topics. Logging should support debugging without exposing unnecessary content. Retention and access to retrieval logs should be governed just like application and security logs.

16. Performance Planning and Benchmarking

A useful benchmark represents the application, not the marketing demo. Build a test corpus with realistic vector dimensions, metadata distributions, document sizes, update frequency, and tenant skew. Replay the query patterns that matter: semantic-only, heavily filtered, hybrid, multilingual, high-concurrency, and burst scenarios.

16.1 Metrics to Measure

• Retrieval recall against an exact or trusted reference set.
• Median, p95, and p99 query latency under realistic concurrency.
• Throughput at the latency target, not only maximum throughput.
• Latency and recall under selective metadata or permission filters.
• Index build and rebuild duration.
• Ingestion and update rate while queries are running.
• Memory, CPU, storage, and I/O footprint.
• Recovery time after restart, failover, or node replacement.
• Cost per workload at current size and projected growth.
• Operational effort required to maintain target quality and latency.

16.2 Test Writes and Maintenance, Not Only Reads

RAG corpora change. Documents are added, edited, deleted, re-chunked, and re-embedded. Index maintenance can affect query latency and resource use. A benchmark that loads a static dataset once and tests only reads may hide the operational behavior that dominates production.

16.3 Benchmark Filtering Separately

Measure low-selectivity and high-selectivity filters separately. A filter that matches half the corpus behaves differently from a filter that matches one percent. Include tenant skew as well: one large tenant can create very different performance characteristics from thousands of small tenants.

17. Cost and Operational Complexity

Cost should include more than the database bill. A dedicated vector system may add managed-service fees, networking, duplicated storage, observability, backup, engineering time, data synchronization infrastructure, and incident response overhead. Conversely, forcing a growing vector workload into PostgreSQL can increase database size, memory requirements, maintenance windows, replica costs, and risk to transactional workloads.

The right comparison is total cost of ownership for the target service level. A more expensive managed vector database can be cheaper overall if it removes substantial platform engineering. A lower-cost pgvector deployment can be superior if the team already operates PostgreSQL efficiently and the workload fits comfortably.

17.1 Questions for a Cost Review

• How much duplicated data exists in a split-store design?
• How often will the corpus be re-embedded?
• What is the cost of replicas, backups, and staging environments?
• Does cross-region or cross-service data transfer add cost?
• How much engineer time is needed for tuning, upgrades, and incidents?
• Can the retrieval service scale down during quiet periods?
• Will vector growth force the transactional database onto a larger instance class?
• What is the cost of vendor lock-in or a future migration?

18. Reliability, Backup, and Disaster Recovery

Vector data is often reproducible from source documents and an embedding model, but rebuilding it can still take significant time and compute. Decide whether vectors are primary data, derived data, or a cache with an expensive rebuild. That classification determines backup and recovery expectations.

With pgvector, existing PostgreSQL backup and replication procedures can cover both relational data and vectors. That can simplify point-in-time recovery and consistency. In a dedicated system, you need to understand the vendor’s or product’s snapshot, replication, restore, and regional-failure model. The architecture should also define how PostgreSQL and the vector store are reconciled after partial recovery.

Do not assume that “we can regenerate embeddings” is a complete disaster-recovery plan. Rebuilding may depend on model availability, model version, source-document completeness, external APIs, rate limits, and significant compute cost. Recovery time should be measured, not guessed.

19. Migration Strategy and Exit Planning

A good starting architecture should not become a permanent trap. Keep the retrieval layer conceptually separate from business logic so storage can change later. Application components should depend on a retrieval contract—what goes in, what comes back, what metadata is required, and what quality guarantees matter—rather than exposing every product-specific feature throughout the codebase.

19.1 Start Simple, Measure, Then Specialize

If PostgreSQL already exists, a sensible path is often to start with pgvector, establish relevance metrics, and observe real workload growth. Migration should be triggered by measured pain: unacceptable p99 latency, filtered recall degradation, resource contention, operational isolation needs, or specialized retrieval requirements.

19.2 Dual-Run Before Cutover

When migrating, run both retrieval systems against the same representative traffic for a period. Compare relevance, latency, errors, filter correctness, and cost. A database migration is not complete merely because the new system returns results; it must preserve the behavioral guarantees the application depends on.

19.3 Define Rollback Before Migration

A rollback path should exist before production traffic moves. Keep the old system current long enough to reverse the cutover if retrieval quality, permissions, latency, or operational behavior regress. This is especially important when the new vector database uses a different ranking or filtering model.

20. Real-World Decision Scenarios

21. Common Mistakes

21.1 Choosing by Vector Count Alone

Vector count is easy to communicate but incomplete. Dimension, query rate, filters, update rate, recall target, concurrency, hardware, and tenancy can change the result. Use vector count as one input, not a universal threshold.

21.2 Benchmarking Without Filters

Unfiltered nearest-neighbor tests can hide the hardest part of production RAG. If authorization or metadata filters are common, include them from the first benchmark.

21.3 Adding a Dedicated Database Before You Have a Workload

Premature specialization creates operational cost before it creates user value. Start with the simplest architecture that meets current requirements and keep the retrieval layer replaceable.

21.4 Treating the Vector Store as the Authorization System

Vector metadata can support filtering, but the system still needs an authoritative access model. Do not let a convenient metadata field become the only security boundary without a deliberate design and negative security testing.

21.5 Ignoring Re-Embedding Cost

Embedding models change. If the entire corpus must be reprocessed, the system may temporarily require double storage, higher write throughput, and large indexing work. Include this lifecycle in capacity planning.

21.6 Optimizing Infrastructure Before Retrieval Quality

A fast database cannot rescue poor chunking, weak embeddings, missing metadata, or a retrieval strategy that does not match user intent. Measure answer quality and retrieval quality before spending heavily on micro-optimizing vector latency.

22. Best-Practice Checklist

• Define the user-facing latency and retrieval-quality targets before selecting a database.
• Use exact search or a trusted reference process to measure approximate-search recall.
• Benchmark realistic filters, tenant distributions, and authorization constraints.
• Include writes, deletes, re-embedding, and index maintenance in performance tests.
• Prefer pgvector when PostgreSQL is already authoritative and the workload fits comfortably.
• Choose a dedicated vector database only when specific measured requirements justify the extra system.
• Keep the retrieval interface abstract enough to support future migration.
• Define source of truth, synchronization guarantees, and deletion behavior in split-store designs.
• Treat vectors and retrieval logs as governed data assets.
• Test tenant isolation and permission revocation as security requirements.
• Monitor p95 and p99 latency, not only averages.
• Monitor retrieval quality after index, model, or corpus changes.
• Plan for full-corpus re-embedding and index rebuilds.
• Include backup, restore, and disaster recovery in architecture evaluation.
• Review total cost of ownership rather than comparing only service prices.
• Revisit the decision when workload shape changes, not on a fixed calendar.

23. Troubleshooting a Vector Retrieval Architecture

24. Frequently Asked Questions

Do I need a dedicated vector database for RAG?

Not necessarily. If your application already uses PostgreSQL and the vector workload is moderate, pgvector can be a strong starting point. A dedicated vector database becomes more compelling when scale, filtered recall, tail latency, independent scaling, multitenancy, or specialized retrieval features exceed what your Postgres architecture can comfortably deliver.

Is pgvector a real vector database?

pgvector turns PostgreSQL into a system capable of storing vectors and performing exact and approximate similarity search. It supports HNSW and IVFFlat indexes. Whether you call it a “vector database” is less important than whether it meets your retrieval, filtering, consistency, and operational requirements. [2]

Is pgvector good enough for production?

Yes, for many production workloads. The key is to benchmark your actual corpus, vector dimensions, query rate, filters, writes, and recall target. Production readiness is a property of the complete architecture and operations, not the extension name alone.

When should I move from pgvector to a dedicated vector database?

Move when measured evidence shows a clear need: persistent resource contention with transactional workloads, unacceptable p95 or p99 latency, filtered recall problems, independent scaling requirements, very large distributed indexes, or specialized retrieval features that would otherwise require excessive custom engineering.

Which is faster: pgvector or a dedicated vector database?

There is no universal answer. Performance depends on index type, hardware, corpus size, dimensions, filters, concurrency, recall target, quantization, caching, and product implementation. Benchmark the exact workload rather than relying on one published throughput number.

What is the difference between HNSW and IVFFlat?

Both are approximate nearest-neighbor approaches supported by pgvector. HNSW generally offers a better query speed-versus-recall trade-off but uses more memory and builds more slowly. IVFFlat usually builds faster and uses less memory but requires careful list and probe tuning. [2]

Why is filtered vector search difficult?

Approximate search first explores a limited candidate region. If a later filter rejects many of those candidates, the system may need to search deeper to return enough valid results. Filter-aware indexes, iterative scans, partitioning, or specialized vector filtering can reduce this problem depending on the architecture.

Is hybrid search better than vector search alone?

Often, but not always. Hybrid search is valuable when users need both semantic understanding and exact keyword matching. Technical terms, identifiers, names, and product codes are common cases where lexical signals improve dense retrieval. Relevance should be measured on representative queries. [3][4][5][6]

How does multitenancy affect the choice?

Multitenancy increases the importance of isolation, filter selectivity, authorization correctness, and noisy-neighbor behavior. PostgreSQL can centralize tenant and permission logic, while dedicated systems may offer namespaces, partitions, or tenant-oriented primitives. Choose the model you can secure and operate reliably.

Can I start with pgvector and migrate later?

Yes. This is often a practical strategy if the retrieval interface is kept separate from business logic. Define a migration contract early, preserve stable document identifiers, keep source data authoritative, and measure relevance during any future dual-run cutover.

What should I benchmark before choosing?

At minimum, measure recall, p50/p95/p99 latency, throughput, filtered queries, tenant skew, hybrid retrieval if used, update and delete behavior, index builds, recovery, resource consumption, and total cost at current and projected scale.

What is the biggest architectural risk of a separate vector database?

The most common hidden risk is data and authorization synchronization. A second store creates another copy of metadata that must remain correct when documents, tenants, permissions, and lifecycle states change.

25. Conclusion

The pgvector-versus-vector-database decision should not be reduced to “general database versus specialized database” or to a single vector-count threshold. The real choice is between two operational models. One keeps vector retrieval close to the application’s relational source of truth. The other creates an independently scalable retrieval platform with vector-specific features and its own lifecycle.

For many teams already running PostgreSQL, pgvector is the rational first step because it minimizes infrastructure and consistency complexity while providing mature exact and approximate vector search. A dedicated vector database becomes the stronger choice when retrieval is large enough, specialized enough, or operationally important enough to justify a separate system.

The best architecture is therefore evidence-driven and reversible: start with the simplest design that meets current requirements, benchmark realistic filters and quality, monitor tail latency and resource contention, define migration triggers, and specialize only when the workload proves that specialization is valuable.