A team's Pinecone bill 5x'd month over month with no traffic change. Order the most likely causes to investigate, from most likely to least likely.

When a managed vector database bill suddenly jumps without a traffic change, the bill is almost always responding to a quiet change in what you are storing. Vendor pricing is generally stable; engineering pipelines change every week. The correct ordering from most likely to least likely: **1. Embedding model upgrade.** Someone on the team swapped text-embedding-3-small (1536 dims) for text-embedding-3-large (3072 dims) or a similar change. Storage doubled overnight. This is the most common single cause of unexpected bill increases. **2. Chunk size halved.** A content pipeline change reduced chunk size from 1000 tokens to 500 tokens. Same documents, twice as many vectors. Also very common because chunkers are often tuned without coordination with the index owner. **3. Stale namespaces.** A re-indexing run created new namespaces but the old ones were never deleted, so you are paying for two copies of the corpus. Common after migrations. **4. Replication tier left raised.** An availability incident bumped the tier and nobody reverted it. Real but rarer than the data-side causes. **5. Disabled tombstone cleanup.** A background job that reclaims deleted-vector space stopped running, inflating the live count. Vendor-side and very rare. Debug strategy: run a diff on your embedding model version and chunker config first, then count namespaces, then check replication tier.

**Investigate from highest frequency in the wild downward.** The wrong instinct is to chase the most dramatic possible explanation; the right one is to chase the most common. Most cost blowups on managed vector DBs come from pipeline-side changes that silently doubled the data volume: 1. **Embedding model upgrade**: a team migrated from a smaller-dim model to a larger-dim one. The 1536-to-3072 jump (text-embedding-3-small to -large) is the canonical example; per-vector storage doubles. Always check the embedding model version before anything else. 2. **Chunk size halved**: a content pipeline change reduced chunk size from 1000 to 500 tokens. Same corpus, twice the vector count. Often done by a different team to improve retrieval quality without coordinating with the cost owner. 3. **Stale namespaces or collections**: re-indexing runs that created new namespaces while leaving the old ones in place. The user sees no change because traffic routes only to the new namespace; the bill keeps charging for both. 4. **Replication tier left raised**: an availability incident bumped the index to multi-AZ and the rollback step was skipped. Real but less common than the data-side causes because it requires a specific operational event. 5. **Tombstone cleanup disabled**: vendor-side background job that reclaims space from deleted vectors stopped running. The bill counts the live-vector count, which now includes dead rows. Rare because vendor SREs catch this faster than customers. The correct investigation order is: pull the embedding model version and chunker config diff first, then the index inventory (namespaces, collections), then the replication tier, then the dead-vector count. This sequence resolves about 90 percent of real bill blowups before reaching step 4.