Vector database

Many RAG applications, semantic search solutions and AI agents that work with enterprise data rely on vector search. It provides a way to store embeddings and quickly retrieve the most relevant pieces of information for a language model, giving it access to meaningful context from your own data.

OptimaData helps organisations design, implement, optimise and manage vector databases. Whether that means a dedicated solution such as Pinecone or Weaviate, or adding vector capabilities to a database you already use, such as pgvector for PostgreSQL. Our Database Platform Engineers combine years of database expertise with hands-on knowledge of embeddings, indexing strategies and retrieval patterns.

A vector database stores vector representations (embeddings) of text, images and other types of data. An embedding is a sequence of numbers that represents characteristics and meaning found in the original data.

Instead of relying solely on exact matches, vector search allows you to search by similarity: which vectors are closest to each other in vector space?

For larger datasets, this is often done using approximate nearest neighbour (ANN) search. ANN makes it possible to retrieve relevant context based on similarity rather than exact keywords alone. This makes vector search a widely used building block for RAG applications and semantic search.

Common indexing algorithms include HNSW (Hierarchical Navigable Small World) and IVFFlat. Both involve trade-offs between speed, memory usage and accuracy (recall). Getting that balance right is where many implementations run into problems. A poorly configured index may be extremely fast but return less relevant results or highly accurate but too slow for production workloads.

A few years ago, vector search was mainly used in specialised applications. With the rapid adoption of generative AI, RAG and semantic search, it has become an important part of many modern AI projects.

The problem is that vector databases are often treated as standalone components, isolated from the rest of the data platform. Without an integrated approach, this can lead to outdated or duplicated data in the vector store, embeddings that no longer match the source data, and retrieval that becomes slower or less accurate as data volumes grow.

This is exactly why we say: your AI is only as intelligent as your database.

A vector database is not a replacement for a solid data foundation. It is an additional layer or capability within your data platform, and it deserves the same attention to data quality, indexing, security and performance as any other business-critical database.

There are many vector database solutions available today, with significant differences in architecture, scalability, cost and how well they integrate with your existing technology stack.

Below is an overview of some of the most widely used options. The list is not exhaustive and continues to evolve as the market develops.

pgvector (PostgreSQL)

pgvector is an extension that adds vector similarity search directly to PostgreSQL. There is no need for a separate vector database or separate infrastructure: relational data, metadata and vectors can live side by side in the same PostgreSQL database — and even in the same tables.

Key advantages:

• One platform for relational data and vectors, using the transactional capabilities and tooling already available in PostgreSQL
• No separate synchronisation layer between PostgreSQL and an external vector store: source data and embeddings can be managed within the same database
• Supports both HNSW and IVFFlat and benefits from PostgreSQL’s mature ecosystem for querying, filtering and indexing
• Fits naturally into an existing PostgreSQL environment without necessarily introducing another database platform

Key considerations:

• For very large datasets or workloads heavily optimised around vector retrieval, specialised vector databases may offer advantages in scalability or retrieval performance
• Tuning HNSW parameters such as m, ef_construction and ef_search requires database and performance expertise and is easily underestimated
• Horizontal scaling requires a PostgreSQL scaling strategy, while specialised vector platforms may offer different or more integrated mechanisms for distributed scaling

One important consideration: if the original text or source data changes, pgvector does not automatically generate a new embedding. Your application or data pipeline remains responsible for regenerating and storing the embedding.

Pinecone

Pinecone is a fully managed vector database designed specifically for large-scale similarity search. Rather than managing the underlying database infrastructure yourself, you primarily interact with the platform through APIs and managed services.

Key advantages:

• Relatively easy to get started without operating your own vector database cluster
• Designed for large-scale vector retrieval
• Managed and serverless options that can scale with usage

Key considerations:

• Runs as a separate platform alongside your existing data sources, requiring attention to synchronisation between source data and the vector store
• Provides less control over the underlying infrastructure than a self-hosted solution
• Costs depend on factors such as storage, query volume and usage patterns and should be modelled carefully for larger workloads

Weaviate

Weaviate is an open-source vector database with support for vector search and hybrid search, combining semantic vector search with traditional keyword search.

Key advantages:

• Strong support for hybrid search, combining semantic relevance with keyword-based retrieval
• Modular architecture with integrations for a range of embedding and AI models
• Available both self-hosted and as a managed service through Weaviate Cloud

Key considerations:

• Self-hosting requires operational knowledge of an additional database platform
• Data modelling, collections and vectorisation settings require careful design
• When Weaviate runs alongside an existing operational database, synchronisation between the source data and vector store needs to be implemented and monitored

Qdrant

Qdrant is an open-source vector database written in Rust, with a strong focus on vector retrieval, filtering and efficient resource utilisation.

Key advantages:

• Strong capabilities for combining metadata filtering with vector search
• Supports techniques for optimising memory and storage usage
• Well-documented with active open-source development
• Supports distributed deployments with sharding and replication

Key considerations:

• Introducing another database platform also means additional operational knowledge, monitoring and management
• When Qdrant runs alongside your existing database, synchronisation with the source data needs to be implemented
• Self-hosted distributed deployments require careful consideration of shard distribution, replication, load balancing and capacity

Milvus

Milvus is an open-source vector database designed for large-scale and distributed vector workloads.

Key advantages:

• Designed for large datasets and high-throughput workloads
• Supports multiple indexing algorithms, allowing the platform to be tuned for specific workloads
• An actively developed open-source project within the LF AI & Data ecosystem

Key considerations:

• A distributed architecture with multiple components is more complex to operate than simpler solutions
• For smaller datasets or straightforward use cases, the operational complexity may outweigh the benefits
• Managing a distributed system requires specialised expertise that may not be available in every team

MongoDB Vector Search

MongoDB supports vector search alongside document data, allowing embeddings and their associated data to be combined within the MongoDB platform.

Key advantages:

• A natural option when MongoDB is already part of your data platform
• Combines MongoDB’s document model with vector search and filtering
• MongoDB Atlas provides a fully managed environment with integrated Vector Search capabilities

Key considerations:

• Architecture and operational capabilities differ between Atlas and self-hosted MongoDB environments
• Using MongoDB for vector search means the vector layer becomes part of the same broader platform decision
• For specialised vector workloads, performance, scalability and cost should be benchmarked against dedicated vector databases rather than relying on theoretical differences

Vector Search is no longer exclusive to Atlas. Recent MongoDB versions also provide these capabilities for certain Enterprise and Community deployments. Always check which features are available for the specific version and deployment model you intend to use.

Elasticsearch / OpenSearch

Both platforms have expanded their established search capabilities with vector search, complementing their existing strengths in full-text search and filtering.

Key advantages:

• Strong combination of traditional full-text search, filtering and vector search within a single platform
• Mature ecosystem for monitoring, tooling and operational expertise
• Particularly relevant if Elasticsearch or OpenSearch is already being used for search and you want to add vector capabilities

Key considerations:

• Vector search shares resources and configuration with broader search workloads, making capacity planning and tuning particularly important
• Large vector indexes can require significant CPU, memory and storage capacity
• Differences in licensing, features and development direction between Elasticsearch and OpenSearch require a deliberate platform choice

Azure AI Search

Azure AI Search is Microsoft’s managed search service with integrated vector search and close integration with the wider Azure AI ecosystem.

Key advantages:

• Strong integration with Azure OpenAI and other Azure services
• Fully managed, with support for hybrid search and semantic ranking
• Built-in indexers can connect to a range of Azure data sources

Key considerations:

• Strong dependency on the Azure ecosystem can make it less attractive within a different cloud strategy
• Costs can become significant with larger indexes and high query volumes
• Less direct control over the underlying infrastructure and index implementation than with self-hosted alternatives

Redis Vector Search

Redis supports vector search within the Redis platform and can provide very low latency for real-time applications through its memory-first architecture.

Key advantages:

• Low latency makes it well suited to real-time search and recommendation use cases
• Redis is already present in many technology environments as a caching or data layer, making it possible to add vector search within a familiar platform
• Supports multiple vector indexing methods and optimisation techniques for different performance and memory requirements

Key considerations:

• A memory-first architecture can result in relatively high memory costs for large vector collections
• Capacity planning becomes increasingly important as vectors, metadata and index structures grow
• Persistence, recovery and the role of Redis as a primary or secondary data store should be considered carefully as part of the overall architecture

Regardless of the platform you choose, we see many of the same considerations across vector database implementations.

Managed does not mean optimised

Even with a fully managed vector database, the provider may manage much of the infrastructure, but that does not automatically mean retrieval is optimised for your data and use case.

Index parameters, chunking strategy, embedding model selection and metadata filtering remain important design decisions regardless of the platform you choose.

Garbage in, garbage out, only faster

A vector database does not improve poor-quality source data. It primarily makes that data searchable in a different way.

If your chunking strategy is wrong or your source data is outdated or inconsistent, even technically fast retrieval can return the wrong context. Data quality remains a fundamental part of the solution.

Recall versus speed

Approximate nearest neighbour search involves a practical trade-off between recall, latency and resource usage. Searching more candidates can increase the likelihood of finding the most relevant results, but it also requires more computation.

Getting this balance right (and revisiting it as the dataset grows) is exactly the kind of tuning that is often overlooked during an initial implementation.

Dedicated platform versus extending your existing database

Adding a dedicated vector database means introducing another component that needs to be operated, secured and kept in sync with your source data.

For many organisations, it is therefore worth considering whether adding vector capabilities to a database or search platform they already use could be an equally good or better fit, particularly when the data volume and use case allow for it.

Memory and cost

Vectors can require significant storage and index capacity. A 1,536-dimensional vector stored using 32-bit floating-point values requires approximately 6 KB for the vector values alone.

At one million vectors, that already represents roughly 6 GB of raw vector data, before accounting for metadata, index structures and database overhead.

This translates directly into infrastructure and cloud costs, particularly for memory-intensive solutions. Good capacity planning helps prevent unpleasant surprises later.

Vendor lock-in

The embeddings themselves are generally portable as long as the target platform supports the relevant data type, dimensionality and distance metric.

The larger migration challenge is usually elsewhere: APIs, schemas, metadata filters, index configurations, namespaces or collections, ingestion pipelines and retrieval logic differ between platforms.

Switching platforms can therefore still require substantial work. Choosing deliberately from the start remains important.

We do not see a vector database as an isolated AI component. We see it as an integral part of your data foundation.

Our Database Platform Engineers combine traditional database expertise (indexing, performance tuning and data modelling) with knowledge of embeddings and retrieval patterns, whether you choose pgvector, a specialised vector database or a hybrid approach.

Not sure whether your current data platform is ready for vector search and the AI workloads that will depend on it? That is exactly what our AI Data Readiness QuickScan is designed to assess.