In this article
Context
We need an embedding model for our RAG pipeline. The model determines retrieval quality, vector dimensions (affects storage), and API cost.
Options Evaluated
OpenAI text-embedding-3-small (1536d)
Pros
- +Cheapest OpenAI option ($0.02/1M tokens)
- +Good quality for general text
- +Configurable dimensions (512-1536)
Cons
- −Not best-in-class on MTEB benchmarks
- −Vendor lock-in to OpenAI
OpenAI text-embedding-3-large (3072d)
Pros
- +Top-tier quality on MTEB
- +Configurable dimensions
Cons
- −6.5x more expensive than small variant
- −Higher storage cost (2x dimensions)
Cohere embed-v3
Pros
- +Best multilingual support
- +Input type parameter (search_document vs search_query)
- +Competitive MTEB scores
Cons
- −Additional vendor dependency
- −Less ecosystem tooling
BGE-large-en-v1.5 (open source)
Pros
- +Free — self-hosted
- +Strong MTEB benchmarks
- +No vendor dependency
Cons
- −Must host GPU infrastructure
- −Operational overhead for scaling
Decision
We chose OpenAI text-embedding-3-small with 1536 dimensions. The cost is negligible at our scale (<$5/month), quality is sufficient for our document types (technical articles), and it integrates seamlessly with our existing OpenAI API key. We'll set dimensions to 1024 to reduce storage while maintaining quality.
Consequences
- •Vector dimensions set to 1024 in pgvector schema
- •Locked to OpenAI for embeddings (acceptable — easy to migrate)
- •Must re-embed all documents if we switch models
- •Batch embedding for new content via background job
Related Articles
designing rag systems that actually scale