| 4 min read

Vector Databases for AI Engineers: pgvector vs ChromaDB vs Pinecone

vector databases pgvector ChromaDB Pinecone RAG semantic search

Choosing a Vector Database Matters

If you are building any AI application that involves retrieval, semantic search, or RAG (retrieval-augmented generation), you need a vector database. The question is which one. I have used pgvector, ChromaDB, and Pinecone in production projects, and each has distinct strengths and weaknesses.

This comparison is based on real experience, not benchmarks in isolation. I will cover performance, operational complexity, cost, and the practical tradeoffs that matter when you are actually building things.

pgvector: The Pragmatic Choice

pgvector is a PostgreSQL extension that adds vector similarity search to your existing database. I use it in two production systems: my venue search platform (300+ venues) and Open Brain (2,400+ knowledge chunks).

Strengths

  • No new infrastructure: If you already have PostgreSQL, you just enable the extension. No new service to deploy, monitor, or pay for.
  • SQL integration: You can combine vector similarity with traditional WHERE clauses, JOINs, and aggregations in a single query. This is incredibly powerful for hybrid search.
  • ACID compliance: Your vector data has the same transactional guarantees as the rest of your database.
  • Cost: Free and open source. The only cost is your existing PostgreSQL hosting.

Weaknesses

  • Scaling: pgvector is not designed for billions of vectors. It works well up to a few million, but beyond that you will need to think carefully about indexing and hardware.
  • Indexing options: IVFFlat and HNSW are available, but the tuning options are more limited than dedicated vector databases.
  • No managed service: You manage the infrastructure yourself (unless you use a managed PostgreSQL provider that supports pgvector).
-- pgvector query with hybrid filtering
SELECT v.name, v.category,
       1 - (ve.embedding <=> $1::vector) AS similarity
FROM venues v
JOIN venue_embeddings ve ON v.id = ve.venue_id
WHERE v.category = 'restaurant'
  AND v.price_range <= 3
ORDER BY ve.embedding <=> $1::vector
LIMIT 10;

ChromaDB: The Developer-Friendly Option

ChromaDB is an open-source embedding database designed specifically for AI applications. I used it during prototyping for my document analysis SaaS before switching to pgvector.

Strengths

  • Fastest setup: You can have a working vector database in 3 lines of Python. No server needed for development.
  • Great Python API: The interface is clean and intuitive, designed for AI engineering workflows.
  • Built-in embedding: Chroma can generate embeddings automatically using built-in models, reducing boilerplate.
  • Metadata filtering: Supports filtering on metadata alongside vector search.

Weaknesses

  • Production readiness: Running Chroma in production requires more thought. It is improving rapidly, but it is less battle-tested than PostgreSQL.
  • No SQL: If you need complex queries beyond basic metadata filtering, you are limited.
  • Separate service: In production, it runs as a separate service, adding operational complexity.
import chromadb

client = chromadb.Client()
collection = client.create_collection("venues")

# Add documents
collection.add(
    documents=["Great Italian restaurant with rooftop terrace..."],
    metadatas=[{"category": "restaurant", "price_range": 3}],
    ids=["venue_1"]
)

# Query with metadata filter
results = collection.query(
    query_texts=["romantic dinner spot"],
    where={"category": "restaurant"},
    n_results=10
)

Pinecone: The Managed Scale Option

Pinecone is a fully managed vector database service. I evaluated it for a client project that needed to handle millions of product embeddings.

Strengths

  • Fully managed: Zero infrastructure to maintain. Pinecone handles scaling, backups, and availability.
  • Scale: Designed to handle billions of vectors with consistent performance.
  • Serverless option: Pay-per-query pricing means you do not pay for idle capacity.
  • Namespace support: Built-in multi-tenancy through namespaces.

Weaknesses

  • Cost: Significantly more expensive than self-hosted options at scale. The serverless tier is affordable for small projects, but costs grow quickly.
  • Vendor lock-in: Your data and queries are tied to Pinecone's API. Migrating away requires reindexing everything.
  • No SQL integration: Vector search and your relational data live in separate systems, requiring application-level joins.
  • Latency: Network round-trips add latency compared to a co-located database.

My Recommendation Framework

After using all three in real projects, here is how I decide:

Use pgvector when:

  • You already use PostgreSQL
  • Your dataset is under a few million vectors
  • You need hybrid search (vector + SQL filters)
  • You want to minimise infrastructure and cost
  • You are a solo developer or small team managing your own stack

Use ChromaDB when:

  • You are prototyping quickly and want zero setup friction
  • Your project is Python-centric
  • You want built-in embedding generation
  • You are building a standalone AI tool that does not need a relational database

Use Pinecone when:

  • You need to scale to millions or billions of vectors
  • You want a fully managed service and can afford it
  • Your team does not want to manage database infrastructure
  • You need enterprise features like SSO, audit logs, and SLAs

Performance in Practice

For the scale of my projects (hundreds to thousands of vectors), all three perform excellently. Query times are under 20 milliseconds across the board. The performance differences only become significant at much larger scales.

If your dataset is under 100,000 vectors, performance should not be your primary decision factor. Focus on developer experience, operational simplicity, and how well the database fits into your existing architecture.

My Choice: pgvector

For my projects, pgvector wins. The ability to keep everything in one database, write hybrid SQL queries, and avoid additional services is enormously valuable. It keeps the architecture simple, the costs low, and the deployment straightforward. If I were working at a larger scale with a dedicated infrastructure team and budget, Pinecone would be compelling. But for AI engineers building production systems on lean infrastructure, pgvector is hard to beat.

Steve Light is an AI engineer based in South West England, building multi-agent pipelines, automation tools, and production AI applications. View full CV | More posts