bmax

MongoDB Atlas vector search is fine at a few million documents. At 133 million chunks — about a terabyte, 90% of it embeddings and text — it cost us $10,000 a month, and the two obvious cost-reduction paths both dead-end: Online Archive can't run vector queries at all, and search-node downgrades trade cost for CPU bottlenecks.

The three walls we hit

1. Online Archive doesn't support $vectorSearch. Atlas's cost-reduction story for old data is Online Archive, built on Atlas Data Federation — which explicitly doesn't support the $vectorSearch pipeline stage. If your data is vectors, the archive tier is a dead end, full stop.

2. Search-node economics don't want to be cheap. Downgrading search nodes cut our cost roughly 25%, then CPU usage from triggers became the bottleneck. The architecture prices vector search like database workload, when what you're actually doing is a similarity lookup.

3. Storage and index live at one tier. Most vector data ages out of usefulness — government meeting minutes from 2022 don't generate buying signals in 2026 — but Atlas makes you pay to store and index all of it identically. We found 76.5% of our corpus qualified for cold storage once we built archival ourselves (embeddings stripped, content to S3, lightweight Postgres index for fallback).

What we did instead

Migrated to Turbopuffer via dual-write with a shadow-mode validation period — no big-bang cutover. Object-storage economics changed the bill's shape entirely: same workload, $10K/month → $1,000–1,400/month (current real invoices here), with headroom to 500M documents per namespace.

The full migration write-up, including the embedding model switch that rode along with it: 133 Million Chunks.