Should I use pgvector or Pinecone?

For most projects: pgvector. If your application already uses PostgreSQL, pgvector adds vector search without a new service — simpler architecture, lower cost, fewer moving parts. Choose Pinecone when you need to index tens of millions of vectors with consistently low-latency search, or when the vector store needs to operate independently of your relational database. For early-stage products and typical RAG systems (up to a few million vectors), pgvector is sufficient.

Which embedding models should I use for vector search?

For most English-language applications, OpenAI's text-embedding-3-small offers a good balance of quality and cost. For multilingual applications (Arabic, French, Moroccan Darija), we evaluate multilingual embedding models including Cohere's embed-multilingual and open-source alternatives. Embedding model choice affects retrieval quality significantly — we run retrieval evaluation as part of every RAG project to select the best model for your content.

How accurate is RAG compared to fine-tuning?

For knowledge retrieval tasks — answering questions based on a document corpus — RAG consistently outperforms fine-tuning. Fine-tuning embeds knowledge into model weights and tends to hallucinate when questions go beyond the training distribution. RAG retrieves relevant chunks at query time, grounding the LLM's answer in specific source documents. RAG also allows real-time updates to the knowledge base without retraining. See our RAG vs Fine-tuning comparison for a detailed breakdown.

What is the cost of running a RAG system at scale?

RAG cost has two components: embedding (converting documents and queries to vectors) and generation (the LLM call). Embedding is inexpensive — text-embedding-3-small costs fractions of a cent per million tokens. Generation (GPT-4o or Claude) is the main cost driver. A typical RAG query with 2,000 tokens of context and 500 tokens of response costs approximately $0.01–$0.03 per query at current GPT-4o pricing. High-frequency applications (10,000+ queries/day) should optimise context size and consider caching common queries.

Database

Pinecone / pgvector

Vector databases for semantic search and RAG systems.

Book a Discovery Call Pinecone / pgvector website

Vector databases store and query high-dimensional embeddings for semantic similarity search. We use pgvector (PostgreSQL extension) for projects that already run PostgreSQL, providing vector search without an additional infrastructure dependency. For large-scale standalone vector search (50M+ vectors), we use Pinecone — a managed vector database with sub-10ms query latency at scale.

Why we chose it

Why Ascii-Core uses Pinecone / pgvector

1
Semantic search finds conceptually related content even when exact keywords differ — essential for RAG
2
pgvector integrates with existing PostgreSQL infrastructure — no additional service to manage for most projects
3
Pinecone scales to billions of vectors with consistent query performance — appropriate for large knowledge bases
4
Both support metadata filtering — combine vector similarity with structured attribute filters

Ideal use cases

When to use Pinecone / pgvector

RAG systems requiring semantic document retrieval
AI chatbots that search a knowledge base to answer questions accurately
Recommendation engines based on content similarity
Semantic duplicate detection in document processing pipelines
Multimodal search combining text and image embeddings

Trade-offs

Honest limitations

We believe in accurate trade-offs. These are the cases where a different tool may be the better choice.

pgvector performance degrades at very high vector counts (10M+) without index tuning — Pinecone handles this better
Vector search requires embedding models to convert text to vectors — adds an API call and cost to every search
Approximate nearest neighbour search may miss relevant results at very high recall requirements

Services