With the technical foundations established in Parts 1 and 2, we now face the practical question every development team encounters: which vector database should we actually use? The market offers dozens of options, each claiming superior performance, better developer experience, or lower costs. This part cuts through the marketing noise to provide honest comparisons based on production deployments, real-world benchmarks, and the specific challenges you will encounter at scale.
We will examine six major players: Pinecone, Milvus, Weaviate, Qdrant, Chroma, and pgvector. We will also explore Azure-specific options including SQL Server 2025 and Azure Cosmos DB. The goal is not to declare a single winner, because there is not one. Each database excels in different scenarios, and choosing the right fit depends on your specific requirements around scale, management overhead, performance needs, and integration patterns.
Pinecone: Managed Simplicity at a Premium
Pinecone pioneered the fully managed vector database approach, offering a serverless architecture that abstracts all infrastructure concerns. For teams that want to focus on building applications rather than managing databases, Pinecone provides an attractive proposition.
Architecture and Performance
Pinecone uses proprietary algorithms optimized for low-latency search. The system achieves sub-10 millisecond query times for datasets under 100 million vectors. Benchmarks consistently show Pinecone delivering latencies between 20-50 milliseconds at 10 million vector scale, which meets the requirements for real-time recommendation systems and customer-facing applications.
The serverless tier automatically handles scaling, shard distribution, and replication. You define your vector dimensionality and number of replicas, and Pinecone manages everything else. This operational simplicity comes at the cost of configuration flexibility. You cannot tune index parameters, cannot choose between HNSW and IVF-PQ, and cannot optimize for your specific query patterns.
The Cost Reality
Pinecone pricing follows a consumption model based on pod hours and request units. What appears straightforward becomes complex at scale. A production deployment handling 50 million vectors with moderate query volume can cost between 2,400 and 3,200 dollars monthly, significantly higher than self-hosted alternatives.
The pricing calculator distinguishes between read units and write units, vector dimensions, and pod types. Teams often underestimate costs during proof-of-concept phases, only to discover budget surprises when moving to production. The performance tier, required for meeting strict latency SLAs, adds additional expense.
When Pinecone Makes Sense
Pinecone excels for startups and small teams building customer-facing AI applications with strict SLAs. If your team lacks infrastructure expertise, if you need guaranteed uptime and performance, and if the premium cost fits your budget, Pinecone delivers exceptional developer experience.
It works particularly well for rapid prototyping and MVPs. Deploy in minutes, scale automatically, and avoid operational complexity. Many teams start with Pinecone for proof-of-concept, then evaluate migration to cost-effective alternatives when usage grows.
graph TB
A[Pinecone] --> B[Strengths]
A --> C[Weaknesses]
A --> D[Best For]
B --> B1[Fully Managed]
B --> B2[Fast Deployment]
B --> B3[Auto-scaling]
B --> B4[20-50ms Latency]
B --> B5[99.99% Uptime SLA]
C --> C1[Premium Pricing]
C --> C2[Vendor Lock-in]
C --> C3[Limited Tuning]
C --> C4[No Self-hosting]
D --> D1[Startups]
D --> D2[Quick MVPs]
D --> D3[Real-time Apps]
D --> D4[Teams without DevOps]
E[Cost Example] --> F[50M vectors]
F --> G[768 dimensions]
G --> H[Moderate queries]
H --> I[$2,400-3,200/month]
style A fill:#e1f5ff
style B fill:#e1ffe1
style C fill:#ffe1e1
style E fill:#fff4e1Milvus: Open Source Performance Champion
Milvus represents the opposite end of the spectrum from Pinecone: open source, highly configurable, and optimized for maximum performance. Backed by Zilliz, it has matured into a production-ready system handling billion-scale deployments.
Architecture and Scalability
Milvus uses a distributed architecture separating storage, compute, and metadata management. Object storage like S3 handles vector data, query nodes process searches in parallel, and etcd or MySQL manages metadata. This separation enables true horizontal scaling. Add query nodes to increase throughput, expand storage independently, and scale each component based on your bottlenecks.
The system supports multiple indexing algorithms including HNSW, IVF-PQ, DiskANN, and SCANN. You can tune parameters like M and efConstruction for HNSW, or configure cluster sizes for IVF. This flexibility allows optimization for your specific data distribution and query patterns. Benchmarks show Milvus achieving under 10 millisecond p50 latency at billion-scale datasets when properly configured.
The Configuration Challenge
Milvus power comes with complexity. Getting optimal performance requires understanding your workload characteristics, choosing the right index type, and tuning dozens of parameters. Teams report spending 2-3 weeks optimizing configurations for production deployments. The learning curve is real, but the performance gains justify the investment for scale-sensitive applications.
Self-hosting requires Kubernetes expertise and operational maturity. Zilliz Cloud offers managed Milvus, reducing operational burden while maintaining the cost advantages of open source. At 50 million vectors, managed Milvus costs roughly 500-800 dollars monthly, significantly less than Pinecone for comparable performance.
When Milvus Makes Sense
Milvus suits organizations building high-scale systems requiring maximum performance and cost efficiency. If you have DevOps capabilities, need to handle billions of vectors, and want control over infrastructure decisions, Milvus delivers exceptional value.
It excels for batch processing workloads, data analytics applications, and scenarios where you can invest time in optimization. Companies building in-house AI platforms or serving millions of users choose Milvus for its scalability and lower operational costs compared to managed alternatives.
Here is a Python implementation using Milvus for a production RAG system:
from pymilvus import (
connections,
utility,
FieldSchema,
CollectionSchema,
DataType,
Collection,
)
import numpy as np
class MilvusVectorStore:
def __init__(self, host="localhost", port="19530", collection_name="documents"):
"""Initialize Milvus connection and collection"""
self.collection_name = collection_name
# Connect to Milvus
connections.connect(
alias="default",
host=host,
port=port
)
self.collection = None
def create_collection(self, dim=768, max_length=65535):
"""
Create collection with optimized schema
Args:
dim: Vector dimensionality
max_length: Maximum text length
"""
# Define fields
fields = [
FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=max_length),
FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=dim),
FieldSchema(name="metadata", dtype=DataType.JSON)
]
# Create schema
schema = CollectionSchema(
fields=fields,
description="Document embeddings for RAG",
enable_dynamic_field=True
)
# Create collection
self.collection = Collection(
name=self.collection_name,
schema=schema
)
print(f"Collection '{self.collection_name}' created successfully")
def create_index(self, index_type="HNSW", metric_type="COSINE"):
"""
Create optimized index for search
Args:
index_type: HNSW, IVF_FLAT, IVF_PQ, etc.
metric_type: L2, COSINE, IP
"""
if self.collection is None:
self.collection = Collection(self.collection_name)
# Define index parameters based on type
if index_type == "HNSW":
index_params = {
"metric_type": metric_type,
"index_type": "HNSW",
"params": {
"M": 48, # Max connections per node
"efConstruction": 500 # Construction effort
}
}
elif index_type == "IVF_PQ":
index_params = {
"metric_type": metric_type,
"index_type": "IVF_PQ",
"params": {
"nlist": 1024, # Number of clusters
"m": 32, # Number of subquantizers
"nbits": 8 # Bits per subquantizer
}
elif index_type == "IVF_FLAT":
index_params = {
"metric_type": metric_type,
"index_type": "IVF_FLAT",
"params": {
"nlist": 2048
}
}
# Create index
self.collection.create_index(
field_name="embedding",
index_params=index_params
)
print(f"{index_type} index created with {metric_type} metric")
def insert(self, texts, embeddings, metadata=None):
"""
Insert documents with embeddings
Args:
texts: List of text strings
embeddings: List of embedding vectors
metadata: Optional list of metadata dicts
"""
if self.collection is None:
self.collection = Collection(self.collection_name)
if metadata is None:
metadata = [{} for _ in texts]
# Prepare data
data = [
texts,
embeddings,
metadata
]
# Insert
insert_result = self.collection.insert(data)
self.collection.flush()
return insert_result
def search(
self,
query_embedding,
top_k=10,
search_params=None,
filter_expr=None
):
"""
Perform vector similarity search
Args:
query_embedding: Query vector
top_k: Number of results
search_params: Search parameters (ef, nprobe, etc.)
filter_expr: Metadata filter expression
"""
if self.collection is None:
self.collection = Collection(self.collection_name)
# Load collection to memory
self.collection.load()
# Default search params if not provided
if search_params is None:
search_params = {
"metric_type": "COSINE",
"params": {"ef": 100} # For HNSW
}
# Perform search
results = self.collection.search(
data=[query_embedding],
anns_field="embedding",
param=search_params,
limit=top_k,
expr=filter_expr,
output_fields=["text", "metadata"]
)
return results
def hybrid_search(self, query_embedding, filter_conditions, top_k=10):
"""
Hybrid search with metadata filtering
Args:
query_embedding: Query vector
filter_conditions: Dict of filter conditions
top_k: Number of results
"""
# Build filter expression
filter_parts = []
for key, value in filter_conditions.items():
if isinstance(value, str):
filter_parts.append(f'metadata["{key}"] == "{value}"')
elif isinstance(value, (int, float)):
filter_parts.append(f'metadata["{key}"] == {value}')
elif isinstance(value, dict):
# Range query
if "gte" in value:
filter_parts.append(f'metadata["{key}"] >= {value["gte"]}')
if "lte" in value:
filter_parts.append(f'metadata["{key}"] <= {value["lte"]}')
filter_expr = " and ".join(filter_parts) if filter_parts else None
return self.search(
query_embedding=query_embedding,
top_k=top_k,
filter_expr=filter_expr
)
def delete_by_filter(self, filter_expr):
"""Delete documents matching filter"""
if self.collection is None:
self.collection = Collection(self.collection_name)
self.collection.delete(filter_expr)
self.collection.flush()
# Example usage
if __name__ == "__main__":
# Initialize
store = MilvusVectorStore(
host="localhost",
port="19530",
collection_name="rag_documents"
)
# Create collection and index
store.create_collection(dim=768)
store.create_index(index_type="HNSW", metric_type="COSINE")
# Sample data
texts = [
"Azure offers comprehensive cloud services",
"Machine learning enables predictive analytics",
"Vector databases store high-dimensional embeddings"
]
# Generate sample embeddings (in production, use actual embedding model)
embeddings = [np.random.rand(768).tolist() for _ in texts]
metadata = [
{"category": "cloud", "date": "2025-01-15"},
{"category": "ai", "date": "2025-01-16"},
{"category": "database", "date": "2025-01-17"}
]
# Insert
store.insert(texts, embeddings, metadata)
# Search
query_embedding = np.random.rand(768).tolist()
results = store.search(query_embedding, top_k=2)
print("Search results:")
for hits in results:
for hit in hits:
print(f"Text: {hit.entity.get('text')}")
print(f"Score: {hit.score}")
print(f"Metadata: {hit.entity.get('metadata')}")
print()
# Hybrid search with filters
hybrid_results = store.hybrid_search(
query_embedding=query_embedding,
filter_conditions={"category": "ai"},
top_k=5
)
print("Hybrid search results (category=ai):")
for hits in hybrid_results:
for hit in hits:
print(f"Text: {hit.entity.get('text')}")
print(f"Metadata: {hit.entity.get('metadata')}")graph TB
A[Milvus] --> B[Strengths]
A --> C[Weaknesses]
A --> D[Best For]
B --> B1[Open Source]
B --> B2[High Performance]
B --> B3[Flexible Indexing]
B --> B4[Cost Effective]
B --> B5[Billion-scale Ready]
C --> C1[Complex Setup]
C --> C2[Steep Learning Curve]
C --> C3[Requires K8s Skills]
C --> C4[Tuning Overhead]
D --> D1[Large Scale Apps]
D --> D2[Cost-sensitive Projects]
D --> D3[Custom Requirements]
D --> D4[Teams with DevOps]
E[Architecture] --> F[Storage Layer]
E --> G[Compute Layer]
E --> H[Metadata Layer]
F --> F1[S3/MinIO]
G --> G1[Query Nodes]
G --> G2[Index Nodes]
H --> H1[etcd/MySQL]
style A fill:#e1f5ff
style B fill:#e1ffe1
style C fill:#ffe1e1
style E fill:#fff4e1Weaviate: Hybrid Search Pioneer
Weaviate distinguishes itself by combining vector search with knowledge graph capabilities and offering sophisticated hybrid search out of the box. This makes it particularly strong for applications requiring both semantic similarity and structured data relationships.
Architecture and Features
Weaviate uses GraphQL as its query interface, providing flexibility for complex queries. The modular architecture allows plugging in different vectorization models, from OpenAI and Cohere to custom transformers running locally. This modularity reduces external dependencies and enables air-gapped deployments.
The hybrid search implementation combines BM25 keyword scoring with vector similarity, using a tunable alpha parameter to control the balance. An alpha of 1.0 gives pure vector search, 0.0 gives pure keyword search, and values between blend both approaches. This flexibility makes Weaviate excellent for applications where users might search with specific keywords alongside semantic queries.
Performance sits between Pinecone and Milvus. Benchmarks show Weaviate achieving 50-100 millisecond latencies for datasets under 10 million vectors. It scales well to tens of millions of vectors but requires larger instances and careful tuning for billion-scale deployments.
Deployment Options
Weaviate offers both open source self-hosting and managed cloud service. The open source version provides complete control and zero vendor lock-in. Weaviate Cloud simplifies operations while maintaining reasonable costs, typically 800-1200 dollars monthly for 50 million vectors, competitive with managed Milvus but less than Pinecone.
The Docker-based deployment makes local development straightforward. Teams familiar with containerization can run Weaviate without Kubernetes complexity, lowering the operational barrier compared to Milvus.
When Weaviate Makes Sense
Weaviate excels when your application needs sophisticated filtering alongside semantic search. E-commerce platforms filtering by price, category, and availability while finding visually similar products benefit from Weaviate's hybrid approach. Content platforms combining keyword matching with semantic understanding leverage its built-in capabilities.
Teams preferring GraphQL over REST APIs find Weaviate natural to integrate. Organizations requiring on-premises deployment with modern features choose Weaviate for its balance of capability and operational simplicity.
Qdrant: Rust Performance with Rich Filtering
Qdrant brings Rust performance characteristics to vector search while emphasizing sophisticated payload filtering. Written in Rust, it offers memory safety and performance while remaining operationally simpler than Milvus.
Architecture and Performance
Qdrant implements HNSW indexing with optimizations for Rust zero-cost abstractions. The system achieves competitive performance with Pinecone and Milvus while consuming less memory. Benchmarks show 20-40 millisecond latencies at 10 million vector scale, meeting real-time application requirements.
The payload filtering system allows complex metadata queries with minimal performance impact. Unlike some databases where filters hurt performance significantly, Qdrant optimizes filter evaluation to maintain fast search even with multiple filter conditions. This makes it excellent for multi-tenant applications or scenarios requiring precise control over search scope.
Developer Experience
Qdrant offers both gRPC and REST APIs with comprehensive client libraries for Python, Go, Rust, and JavaScript. The API design emphasizes simplicity without sacrificing power. Teams appreciate the clear documentation and straightforward deployment model.
Both self-hosted and managed options exist. The self-hosted version runs as a single binary or Docker container, simpler than Milvus distributed architecture. Qdrant Cloud provides managed service at competitive pricing, roughly 600-1000 dollars monthly for 50 million vectors.
When Qdrant Makes Sense
Choose Qdrant when you need sophisticated filtering with minimal performance impact. Multi-tenant SaaS applications isolating customer data through payload filters benefit from Qdrant's optimizations. Applications requiring real-time updates with immediate searchability leverage its efficient indexing.
Teams preferring Rust performance characteristics or gRPC communication choose Qdrant. Organizations wanting managed service simplicity without Pinecone pricing find Qdrant Cloud compelling.
Chroma: Lightweight for Development
Chroma targets the development and prototyping use case, prioritizing simplicity and fast iteration over production scale. It excels as a learning tool and quick start option.
Architecture and Limitations
Chroma runs in-process or as a lightweight server, perfect for notebooks and local development. The API design minimizes boilerplate, letting you insert and query vectors in just a few lines of code. This simplicity comes with scale limitations. Chroma handles thousands to low millions of vectors efficiently but struggles beyond that.
Performance is adequate for development workloads. Search latencies around 20-50 milliseconds for 100,000 vectors make it suitable for prototypes and demos. The lack of advanced indexing options and distributed architecture means production applications outgrow Chroma quickly.
When Chroma Makes Sense
Use Chroma for rapid prototyping, learning vector search concepts, and building MVPs. Its zero-configuration approach and minimal dependencies make it ideal for experimentation. Many teams start with Chroma to validate concepts, then migrate to Pinecone, Milvus, or Weaviate for production deployment.
Small-scale applications serving hundreds of users with thousands of documents can run on Chroma successfully. The embedded option makes it trivial to add vector search to existing Python applications without managing separate databases.
graph TB
A[Weaviate] --> A1[Hybrid Search]
A --> A2[GraphQL API]
A --> A3[Modular Design]
B[Qdrant] --> B1[Rust Performance]
B --> B2[Rich Filtering]
B --> B3[gRPC + REST]
C[Chroma] --> C1[Lightweight]
C --> C2[Easy Setup]
C --> C3[Development Focus]
D[Use Cases] --> D1[Weaviate]
D --> D2[Qdrant]
D --> D3[Chroma]
D1 --> E1[E-commerce Search]
D1 --> E2[Content Platforms]
D1 --> E3[Knowledge Graphs]
D2 --> F1[Multi-tenant SaaS]
D2 --> F2[Real-time Updates]
D2 --> F3[Complex Filters]
D3 --> G1[Prototyping]
D3 --> G2[Learning]
D3 --> G3[Small Apps]
H[Performance Comparison] --> I[100K vectors]
I --> J[Weaviate: 50-100ms]
I --> K[Qdrant: 20-40ms]
I --> L[Chroma: 20-50ms]
style A fill:#e1f5ff
style B fill:#ffe1e1
style C fill:#e1ffe1
style H fill:#fff4e1pgvector: SQL Familiarity Meets Vector Search
The pgvector extension brings vector capabilities to PostgreSQL, offering a compelling option for teams already invested in the PostgreSQL ecosystem. Rather than introducing a new database, you add vector search to your existing relational database.
Architecture and Integration
pgvector adds a vector data type to PostgreSQL, along with operators for distance calculations and index types for efficient search. You can store vectors alongside traditional relational data, join vector searches with SQL queries, and leverage PostgreSQL's transaction support and ACID guarantees.
The extension supports both IVFFlat and HNSW indexes. IVFFlat provides good performance for moderate scale, while HNSW enables billion-scale deployments with proper hardware. Performance depends heavily on your PostgreSQL configuration and hardware. Optimized deployments achieve 10-50 millisecond latencies for millions of vectors.
Scale Considerations
pgvector realistically handles 10-100 million vectors before performance degrades unacceptably. This limitation comes from PostgreSQL's architecture, not designed specifically for vector workloads. For applications within this range, pgvector offers exceptional simplicity by eliminating a separate vector database.
Azure Database for PostgreSQL and Azure Cosmos DB for PostgreSQL both support pgvector, providing managed options with built-in high availability and backups. The integration with Azure ecosystem makes it natural for Azure-centric architectures.
When pgvector Makes Sense
Choose pgvector when your team already runs PostgreSQL and your scale requirements fit within its limits. Applications needing to combine vector search with complex relational queries benefit from keeping everything in one database. The operational simplicity of managing one system instead of two provides significant value.
Organizations with strong PostgreSQL expertise find pgvector natural to adopt. The SQL interface means no new query language to learn. Standard PostgreSQL tools work for monitoring, backup, and administration.
Here is a Node.js implementation using pgvector on Azure Cosmos DB for PostgreSQL:
const { Client } = require('pg');
const fs = require('fs').promises;
class PgVectorStore {
constructor(connectionConfig) {
this.client = new Client(connectionConfig);
this.isConnected = false;
}
async connect() {
if (!this.isConnected) {
await this.client.connect();
this.isConnected = true;
// Enable pgvector extension
await this.client.query('CREATE EXTENSION IF NOT EXISTS vector');
}
}
async disconnect() {
if (this.isConnected) {
await this.client.end();
this.isConnected = false;
}
}
async createTable(tableName, vectorDim, options = {}) {
const {
hasMetadata = true,
additionalColumns = []
} = options;
let sql = `
CREATE TABLE IF NOT EXISTS ${tableName} (
id SERIAL PRIMARY KEY,
content TEXT NOT NULL,
embedding vector(${vectorDim})
`;
if (hasMetadata) {
sql += `,\n metadata JSONB`;
}
for (const col of additionalColumns) {
sql += `,\n ${col.name} ${col.type}`;
}
sql += `\n )`;
await this.client.query(sql);
console.log(`Table ${tableName} created`);
}
async createIndex(tableName, indexType = 'hnsw', options = {}) {
const indexName = `${tableName}_embedding_idx`;
let sql;
if (indexType === 'hnsw') {
const { m = 16, efConstruction = 64 } = options;
sql = `
CREATE INDEX IF NOT EXISTS ${indexName}
ON ${tableName}
USING hnsw (embedding vector_cosine_ops)
WITH (m = ${m}, ef_construction = ${efConstruction})
`;
} else if (indexType === 'ivfflat') {
const { lists = 100 } = options;
sql = `
CREATE INDEX IF NOT EXISTS ${indexName}
ON ${tableName}
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = ${lists})
`;
}
await this.client.query(sql);
console.log(`${indexType.toUpperCase()} index created on ${tableName}`);
}
async insert(tableName, records) {
if (records.length === 0) return;
const values = [];
const placeholders = [];
let paramCount = 1;
for (let i = 0; i < records.length; i++) {
const { content, embedding, metadata } = records[i];
placeholders.push(
`($${paramCount}, $${paramCount + 1}, $${paramCount + 2})`
);
values.push(
content,
JSON.stringify(embedding),
metadata ? JSON.stringify(metadata) : null
);
paramCount += 3;
}
const sql = `
INSERT INTO ${tableName} (content, embedding, metadata)
VALUES ${placeholders.join(', ')}
RETURNING id
`;
const result = await this.client.query(sql, values);
return result.rows.map(row => row.id);
}
async search(tableName, queryEmbedding, limit = 10, options = {}) {
const {
metadataFilter,
distanceThreshold,
operator = '<=>' // cosine distance
} = options;
let whereClause = '';
const params = [JSON.stringify(queryEmbedding), limit];
let paramCount = 3;
if (metadataFilter) {
const filters = [];
for (const [key, value] of Object.entries(metadataFilter)) {
filters.push(`metadata->>'${key}' = $${paramCount}`);
params.push(value);
paramCount++;
}
whereClause = 'WHERE ' + filters.join(' AND ');
}
if (distanceThreshold !== undefined) {
const connector = whereClause ? 'AND' : 'WHERE';
whereClause += ` ${connector} (embedding ${operator} $1::vector) < $${paramCount}`;
params.push(distanceThreshold);
paramCount++;
}
const sql = `
SELECT
id,
content,
metadata,
(embedding ${operator} $1::vector) as distance
FROM ${tableName}
${whereClause}
ORDER BY embedding ${operator} $1::vector
LIMIT $2
`;
const result = await this.client.query(sql, params);
return result.rows;
}
async hybridSearch(
tableName,
queryEmbedding,
queryText,
limit = 10,
vectorWeight = 0.7
) {
const keywordWeight = 1 - vectorWeight;
const sql = `
SELECT
id,
content,
metadata,
(
${vectorWeight} * (1 - (embedding <=> $1::vector)) +
${keywordWeight} * ts_rank(to_tsvector('english', content), plainto_tsquery('english', $2))
) as hybrid_score,
(embedding <=> $1::vector) as vector_distance
FROM ${tableName}
WHERE to_tsvector('english', content) @@ plainto_tsquery('english', $2)
OR (embedding <=> $1::vector) < 1.0
ORDER BY hybrid_score DESC
LIMIT $3
`;
const result = await this.client.query(sql, [
JSON.stringify(queryEmbedding),
queryText,
limit
]);
return result.rows;
}
async deleteByFilter(tableName, metadataFilter) {
const filters = [];
const params = [];
let paramCount = 1;
for (const [key, value] of Object.entries(metadataFilter)) {
filters.push(`metadata->>'${key}' = $${paramCount}`);
params.push(value);
paramCount++;
}
const sql = `
DELETE FROM ${tableName}
WHERE ${filters.join(' AND ')}
RETURNING id
`;
const result = await this.client.query(sql, params);
return result.rows.map(row => row.id);
}
async getStats(tableName) {
const countResult = await this.client.query(
`SELECT COUNT(*) FROM ${tableName}`
);
const sizeResult = await this.client.query(`
SELECT pg_size_pretty(pg_total_relation_size($1)) as total_size
`, [tableName]);
const indexResult = await this.client.query(`
SELECT indexname, pg_size_pretty(pg_relation_size(indexname::regclass)) as size
FROM pg_indexes
WHERE tablename = $1
`, [tableName]);
return {
totalRows: parseInt(countResult.rows[0].count),
tableSize: sizeResult.rows[0].total_size,
indexes: indexResult.rows
};
}
}
// Example usage
async function main() {
const store = new PgVectorStore({
host: 'your-cosmos-db.postgres.database.azure.com',
port: 5432,
database: 'citus',
user: 'citus',
password: 'your-password',
ssl: { rejectUnauthorized: false }
});
try {
await store.connect();
// Create table
await store.createTable('documents', 768);
// Create HNSW index
await store.createIndex('documents', 'hnsw', {
m: 16,
efConstruction: 64
});
// Insert documents
const documents = [
{
content: 'Azure Cosmos DB offers global distribution',
embedding: Array(768).fill(0).map(() => Math.random()),
metadata: { category: 'azure', type: 'database' }
},
{
content: 'pgvector enables vector search in PostgreSQL',
embedding: Array(768).fill(0).map(() => Math.random()),
metadata: { category: 'postgres', type: 'extension' }
}
];
const ids = await store.insert('documents', documents);
console.log('Inserted document IDs:', ids);
// Vector search
const queryEmbedding = Array(768).fill(0).map(() => Math.random());
const results = await store.search('documents', queryEmbedding, 5);
console.log('Search results:');
results.forEach(result => {
console.log(`ID: ${result.id}`);
console.log(`Content: ${result.content}`);
console.log(`Distance: ${result.distance}`);
console.log('---');
});
// Hybrid search
const hybridResults = await store.hybridSearch(
'documents',
queryEmbedding,
'PostgreSQL vector',
5,
0.7
);
console.log('Hybrid search results:');
hybridResults.forEach(result => {
console.log(`Hybrid score: ${result.hybrid_score}`);
console.log(`Content: ${result.content}`);
});
// Get stats
const stats = await store.getStats('documents');
console.log('Table statistics:', stats);
} finally {
await store.disconnect();
}
}
main().catch(console.error);Azure-Specific Options
For organizations already invested in Azure, several native options provide integrated vector search capabilities without introducing third-party dependencies.
Azure SQL Server 2025
SQL Server 2025 introduces native vector data types and indexing, transforming it into a capable vector database. This represents a significant evolution, bringing vector capabilities to the world's most widely deployed enterprise database.
The implementation supports DiskANN indexing for billion-scale vector search with minimal memory overhead. Unlike HNSW which keeps the entire graph in memory, DiskANN stores most data on SSD while maintaining fast search performance. This makes it practical to run massive vector workloads on standard SQL Server hardware.
Integration with existing SQL Server features provides unique capabilities. Combine vector search with full-text search, transactions, stored procedures, and all the enterprise features organizations depend on. The operational familiarity and existing expertise make SQL Server 2025 compelling for enterprises already standardized on Microsoft data platforms.
Azure Cosmos DB for NoSQL
Azure Cosmos DB for NoSQL added vector search capabilities, providing globally distributed vector operations with multi-region writes. The serverless architecture scales automatically, making it suitable for unpredictable workloads.
Performance characteristics differ from specialized vector databases. Cosmos DB optimizes for global distribution and multi-model data, not pure vector search speed. For applications already using Cosmos DB for document storage, adding vector search eliminates a separate database. For greenfield vector-first applications, dedicated vector databases typically provide better performance per dollar.
Azure AI Search
Azure AI Search offers integrated vector search alongside traditional full-text search. The service excels at hybrid scenarios combining vector similarity with keyword matching, faceting, and advanced search features like semantic ranking.
The managed nature simplifies operations, but performance and costs vary significantly with configuration. For applications requiring sophisticated search experiences beyond pure vector similarity, AI Search provides compelling value. For scenarios needing maximum vector search performance, dedicated databases typically win.
graph TB
A[Azure Vector Options] --> B[pgvector]
A --> C[SQL Server 2025]
A --> D[Cosmos DB NoSQL]
A --> E[AI Search]
B --> B1[PostgreSQL Extension]
B --> B2[10-100M vectors]
B --> B3[HNSW + IVFFlat]
C --> C1[Native Vector Type]
C --> C2[DiskANN Index]
C --> C3[Billion-scale]
C --> C4[Enterprise Features]
D --> D1[Globally Distributed]
D --> D2[Serverless]
D --> D3[Multi-model]
E --> E1[Hybrid Search]
E --> E2[Semantic Ranking]
E --> E3[Managed Service]
F[Decision Tree] --> G{Existing DB?}
G -->|PostgreSQL| B
G -->|SQL Server| C
G -->|Cosmos DB| D
G -->|New| H{Primary Need?}
H -->|Vector Search| I[Dedicated DB]
H -->|Full Search| E
style A fill:#e1f5ff
style F fill:#ffe1e1Decision Framework
Choosing the right vector database requires mapping your specific requirements to database strengths. Here is a practical decision framework based on common scenarios.
For startups and quick MVPs, Pinecone or Chroma make sense. Pinecone if you need production-ready performance immediately, Chroma if you are still validating concepts and want zero operational overhead.
For cost-sensitive large-scale applications, Milvus provides the best performance per dollar. The operational complexity pays off through dramatically lower infrastructure costs at scale. Managed Milvus through Zilliz Cloud reduces operational burden while maintaining cost advantages.
For applications requiring sophisticated metadata filtering, Qdrant or Weaviate excel. Qdrant if you prioritize performance and gRPC communication, Weaviate if you need knowledge graph capabilities or prefer GraphQL.
For teams already invested in PostgreSQL, pgvector eliminates architectural complexity by keeping everything in one database. This makes sense for applications under 50 million vectors where the operational simplicity outweighs the performance limitations.
For Azure-centric enterprises, SQL Server 2025 provides compelling integration with existing Microsoft tooling and expertise. The DiskANN indexing enables billion-scale deployments while leveraging familiar SQL Server operations.
What's Next
This part evaluated the major vector database options, from managed services like Pinecone to open source powerhouses like Milvus, along with Azure-native alternatives. You now understand the performance characteristics, cost tradeoffs, and operational considerations for each solution.
Part 4 will shift from evaluation to implementation. We will build a complete RAG application on Azure, combining Azure OpenAI for embeddings, Azure AI Search for retrieval, and Azure SQL Server 2025 for vector storage. You will see working code in Python, Node.js, and C#, along with deployment configurations for production systems.
The foundation is complete. Time to build.
References
- Medium - Vector Database Comparison: Pinecone vs Weaviate vs Qdrant vs FAISS vs Milvus vs Chroma (2025)
- LiquidMetal AI - Vector Database Comparison (2025)
- Milvus - How do I choose between Pinecone, Weaviate, Milvus, and other vector databases?
- Markaicode - How to Choose the Right Vector Database: Pinecone vs. Weaviate vs. Milvus in 2025
- Data Aspirant - Most Popular Vector Databases You Must Know in 2025
- Microsoft Learn - How to enable and use pgvector - Azure Cosmos DB for PostgreSQL
- Microsoft Learn - Choose an Azure Service for Vector Search
- Microsoft Learn - Integrated Vector Database - Azure Cosmos DB
- Visual Studio Magazine - Empowering AI Applications with Vector Search in SQL Server and Azure Cosmos DB
- Antalyze - Vector Database Comparison 2025: Milvus vs Pinecone vs Weaviate
- LakeFS - Best 17 Vector Databases for 2025
