If you've built a RAG pipeline before, you know the pattern: hook up an embedding model, dump vectors into Pinecone, and forget about it until the invoice shows up. That invoice is where most people first realize embedding dimensionality isn't just a technical detail — it's a direct line item on your bill.
Here's what we found while building FastRAG, and why we ended up forcing 1024 dimensions instead of letting the default ride.
The problem: dimension count is a hidden cost multiplier
Pinecone (like most vector databases) charges based on storage, and storage scales linearly with vector dimensionality. A lot of popular embedding models default to 1536 or higher dimensions. That's not wrong, but it's often more resolution than the retrieval task actually needs — especially for the kind of document-chunk semantic search most RAG apps are doing.
The math is simple: every vector at 1536 dimensions costs roughly 50% more to store than the same vector at 1024 dimensions. Multiply that across every chunk of every document a user uploads, and it adds up fast once you have real usage.
