Vector Search at Scale in 2026: Postgres, Dedicated Vector Databases, Object Storage or the Lakehouse?

A few years ago, vector search was a specialist concern for search engineers and recommendation teams. Retrieval-augmented generation (RAG) and AI agents changed that. Every document, ticket, product, image and code file an organization wants its AI to know about is now turned into one or more embeddings, and those embeddings must be stored, indexed, filtered, secured and kept fresh. For large organizations, the result is hundreds of millions or billions of vectors, which makes vector storage a big data problem in its own right.

The market has responded with options across the stack. PostgreSQL with pgvector brings vectors into the operational database. Dedicated vector databases optimize for low-latency similarity search at scale. Object storage services such as Amazon S3 Vectors now store and query vectors natively at low cost. And lakehouse platforms add vector indexes on top of governed tables. This guide compares these four approaches, offers decision criteria and a reference pattern, and highlights the pitfalls that catch teams as they scale.

Why Vector Storage Became a Big Data Problem

• Volume. Chunking documents for RAG multiplies item counts. A corpus of a few million documents can easily become tens or hundreds of millions of chunks, each with its own embedding.
• Multiple embeddings per item. Teams often keep embeddings from several models, or separate embeddings for titles, bodies and images, and must retain old versions while migrating to new models.
• Freshness. Agents and assistants are expected to know about yesterday’s tickets and this morning’s price change, so pipelines must update vectors continuously.
• Filtering and security. Real queries combine similarity with filters for tenant, permissions, language, date and product line. Access control must apply at retrieval time, not only at ingestion.
• Cost. Keeping large indexes in memory on always-on clusters is expensive. Storage and query costs grow with every new use case.

Most organizations will not choose one vector store. They will tier embeddings like any other data: hot, low-latency indexes for interactive retrieval, and cheaper, larger stores for the long tail.

Option 1: PostgreSQL With pgvector

The pgvector extension adds a vector data type and similarity search to PostgreSQL. According to Databricks’ overview of pgvector, it supports HNSW indexes, which are fast but memory-intensive, and IVFFlat indexes, which use less memory at some cost in query speed. It supports common distance metrics such as L2, cosine and inner product, as well as reduced-precision and sparse vector types for saving memory. Vector similarity can be combined with ordinary SQL filters and joins, and with PostgreSQL full-text search for hybrid retrieval.

• Strengths: vectors live next to the relational data they describe; transactions and joins; familiar operations and tooling; available on every major cloud and in platform-native Postgres services.
• Limitations: the same Databricks overview notes that performance can degrade at very high vector counts without additional optimization, that HNSW indexes need substantial memory, and that Postgres lacks built-in sharding for vector workloads.
• Best for: application-embedded search over millions to tens of millions of vectors, especially where filters and joins with relational data matter.

Option 2: Dedicated Vector Databases

Purpose-built vector databases such as Pinecone, Qdrant, Weaviate, Milvus and others, along with vector capabilities in search engines like OpenSearch and Elasticsearch, are designed for similarity search at scale. They typically offer distributed indexes, quantization, metadata filtering, hybrid search, multi-tenancy features and managed serverless options.

• Strengths: consistent low latency at high query volumes; mature filtering and hybrid search; scaling and sharding handled for you in managed offerings.
• Limitations: another system to secure, govern and synchronize; data duplicated from source systems; costs can rise quickly for large, always-hot indexes.
• Best for: customer-facing search, recommendations and high-traffic RAG services with strict latency requirements.

Option 3: Vector-Native Object Storage

Object storage has started to store and query vectors directly. Amazon S3 Vectors, generally available since December 2025, supports up to 2 billion vectors per index and up to 20 trillion vectors per vector bucket, according to AWS. AWS describes sub-second latency for infrequent queries and around 100 milliseconds or less for frequent queries, claims up to 90% lower total cost than specialized vector databases, and integrates the service with Amazon Bedrock Knowledge Bases and Amazon OpenSearch.

• Strengths: very large scale at low storage cost; serverless with no clusters to manage; durability and security features of object storage.
• Limitations: latency and query features are generally less demanding than in dedicated databases; fewer advanced search features; provider-specific APIs.
• Best for: large, infrequently queried corpora, long-term retention of embeddings, agent memory archives and cost-sensitive RAG over big document collections.

AWS itself positions S3 Vectors as complementary to search services: a cost-efficient tier that can work alongside a low-latency engine for the hottest data.

Option 4: Lakehouse Vector Search

Lakehouse platforms add vector indexes to governed tables. Databricks offers vector search that synchronizes indexes from Delta tables, Snowflake and BigQuery provide vector data types and search functions, and open formats such as Lance bring vector indexes to files on object storage. The appeal is governance: embeddings sit in the same catalog as the source data, with lineage, access policies and pipelines managed together.

• Strengths: unified governance and lineage; embeddings computed and refreshed by the same pipelines that build analytical tables; good for batch enrichment and analytical similarity queries.
• Limitations: latency and concurrency vary by platform; some features are platform-specific; real-time serving may still need a dedicated store.
• Best for: organizations whose source data already lives in the lakehouse, internal RAG over governed data and large-scale batch similarity tasks such as deduplication and clustering.

Index Choices and Their Trade-Offs

Whichever store you choose, the index type largely determines the balance between speed, memory, recall and update cost. Understanding the main families helps you ask vendors the right questions.

• Graph-based indexes (such as HNSW): fast queries with high recall, but memory-hungry and slower to build. Frequent updates and deletes can degrade graph quality over time.
• Cluster-based indexes (such as IVF): partition vectors into clusters and search only the closest ones. They use less memory and build faster, but need tuning of how many clusters to probe to keep recall acceptable.
• Quantized indexes (such as product quantization or binary vectors): compress vectors to reduce memory and cost, often with a re-ranking step on full-precision vectors to recover accuracy.
• Disk-based and object-storage-backed indexes: keep most data on SSD or object storage with a small in-memory structure, trading some latency for much lower cost at very large scale.

Filtered search adds another dimension. Some engines filter before the similarity search, some after, and some integrate filters into index traversal. Highly selective filters can cause poor recall or slow queries if the engine handles them badly, so test with your real filter patterns.

Decision Criteria

1. Scale: current and expected vector counts, including multiple embedding versions.
2. Latency and throughput: required p95 and p99 latency and queries per second, for interactive versus batch workloads.
3. Filtering complexity: how many filters, how selective, and whether filters change frequently. Heavy filtering can hurt recall and latency in some index types.
4. Freshness: how quickly new or changed content must be searchable.
5. Security model: multi-tenancy, row-level permissions and whether retrieval must enforce source-system access rights.
6. Governance: need for lineage, retention policies, deletion propagation and audit across embeddings.
7. Cost: storage, compute, query and data movement costs at realistic scale, plus operational staff time.
8. Ecosystem fit: integration with your cloud, data platform, AI frameworks and agent tooling.

A Tiered Reference Pattern

For many organizations, the most cost-effective architecture tiers vectors by access pattern.

1. Source of truth in the lakehouse. Content, metadata and embeddings are produced by governed pipelines and stored in lakehouse tables with lineage and retention policies.
2. Hot tier for interactive retrieval. The subset of embeddings needed for latency-sensitive applications is synchronized to a dedicated vector database or a Postgres instance with pgvector.
3. Warm and cold tier for scale. Large, less frequently queried collections are stored in vector-native object storage or lakehouse indexes.
4. A retrieval layer. A service or agent tool routes queries to the right tier, applies permission filters and merges results, so applications do not need to know where vectors live.

This pattern keeps governance centralized while letting each tier optimize for its job. The cost of the pattern is synchronization, so automate it and monitor freshness.

Operational Practices That Matter at Scale

• Version embeddings. Store the embedding model name and version with every vector. Plan model migrations as dual-write periods with evaluation before switching.
• Propagate deletions. When source content is deleted or a privacy request arrives, remove vectors from every tier and index. Test this regularly.
• Measure retrieval quality. Track recall and relevance on labeled query sets, not only latency. Index parameters, quantization and filtering affect quality.
• Right-size precision. Reduced-precision or binary vectors and quantization can cut memory and cost substantially; evaluate the quality impact on your data.
• Enforce access at query time. Apply user or tenant permissions in the retrieval layer, ideally derived from source systems, so agents cannot retrieve content the user could not see.
• Monitor cost per query. Attribute vector storage and query costs to applications so growth is visible.

Running a Fair Bake-Off

Before committing to a vector store for a major workload, run a short, structured evaluation.

1. Assemble a representative sample of your real content, at least large enough to exercise the index at production-like scale, with the metadata you will filter on.
2. Build a labeled query set of a few hundred real or realistic questions with known relevant results, so you can measure recall and relevance, not just speed.
3. Test each candidate with the same embedding model, chunking and filters, under realistic concurrency, recording p95 and p99 latency.
4. Measure ingestion and update throughput, index build time and the time for deletions to take effect.
5. Calculate monthly cost at expected scale, including storage, queries, replicas and data transfer.
6. Assess security integration, governance features and operational effort, including upgrades and backups.

Document the results as an architecture decision record so the choice can be revisited as products and prices change.

Pitfalls to Avoid

• Choosing by benchmark alone. Public benchmarks rarely include your filters, data distribution or concurrency. Test with your own workload.
• One giant index for everything. Mixing tenants, languages and content types in one index complicates permissions and quality tuning.
• Forgetting the source of truth. If the vector store becomes the only place embeddings exist, rebuilding after a model change or incident becomes painful.
• Ignoring chunking strategy. Poor chunking produces poor retrieval no matter which store you choose.
• Over-engineering early. For a single application with a few million vectors, pgvector or a managed vector service is often all you need.

A Hypothetical Worked Example

A hypothetical global software company wants AI assistants for customer support, sales and engineering. Its content includes 20 million support tickets, 2 million knowledge articles, product documentation in 12 languages and a large code base, producing hundreds of millions of chunks.

1. All content and embeddings are produced by lakehouse pipelines, with embedding model versions recorded and deletion workflows linked to source systems.
2. Knowledge articles and recent tickets, which the customer-facing assistant queries constantly, are synchronized to a managed vector database with tenant and permission filters.
3. The full ticket history and older documentation versions are stored in vector-native object storage for lower-cost retrieval by internal assistants that tolerate higher latency.
4. The engineering assistant uses lakehouse vector search over code embeddings, where governance and lineage matter more than milliseconds.
5. A retrieval service routes queries, enforces permissions and logs which sources were used for each answer.

The example is illustrative; the right split depends on query patterns, latency needs and cost.

Outlook

Vector search is becoming a feature of every data layer rather than a separate product category. Object storage, operational databases, warehouses, lakehouses and search engines all now store and query embeddings. Expect continued price pressure, larger index limits, better hybrid and filtered search, and tighter integration with agent frameworks and retrieval protocols. The differentiators will shift from raw similarity search speed toward governance, freshness, permission-aware retrieval and cost management. Organizations that treat embeddings as governed data assets, tiered by access pattern, will be best placed to scale AI retrieval without runaway cost.

Conclusion

There is no single best place to store vectors at scale. Postgres with pgvector suits application-embedded search, dedicated vector databases serve demanding low-latency workloads, vector-native object storage handles very large and cost-sensitive collections, and lakehouse vector search brings governance and batch scale. Keep the lakehouse as the source of truth, tier by access pattern, enforce permissions at query time and measure retrieval quality as carefully as latency.

How Hanoi Technology Can Help

Hanoi Technology designs embedding pipelines and tiered vector search architectures that keep AI retrieval fast, governed and cost-effective at scale.

• Big Data
• AI Solutions
• Data Engineering
• AWS

Further Reading

• Amazon S3 Vectors Now Generally Available With Increased Scale and Performance – AWS News Blog
• What Is pgvector? – Databricks