Pinecone workflow: blue-green index deploys for re-embeds

Blue-green deploys for embedding changes

Why

Changing the embedding model changes the dimension, which means a new index. Re-embedding in place on the serving index is impossible (dimension is frozen) and destructive.

Steps

1. Build green. Create docs-v2 (new index) or a v2 namespace with the new dimension and metric. Ingest the full corpus there.
2. Verify green. Stats totals match the corpus; sample queries return sane results; run your recall eval set against green and compare to blue's baseline.
3. Dual-read briefly. Send a slice of production queries to green and log both result sets. Investigate divergences before full cutover.
4. Flip. Update the serving config to the green index or namespace. One config value, one deploy.
5. Hold blue. Keep the old index for a rollback window (days, not hours). Rollback is a config flip back.
6. Delete blue. After the window, delete to stop billing. Confirm no code still references the old name.

Traps

1. Flipping before the ingest finished: green serves partial data and nobody notices for a week. Gate the flip on stats totals.
2. Two writers during dual-read: writes must go to both or to green only with a backfill; pick one and enforce it.
3. Forgetting blue bills: set a calendar reminder at flip time for the deletion. Pod indexes especially.

This workflow composes documented primitives: dimension frozen at creation (index guides), namespace auto-creation and per-namespace stats (namespaces guide), and index deletion. Verified against live docs 2026-09-26.