← Back to Work
Generative AI (K-Bot) Vector DB Structure Design & Embedding Migration
A partition-key multi-tenant design and an embedding-model swap that never stops the service
Collections and partitions grew with every customer and file, while embedding-model changes made the existing vector space incompatible with search.
02 / Constraints
Existing documents had to be re-embedded without stopping the service.
Long-running jobs needed pause, resume, retry, and concurrency controls.
Deleted documents could not reappear in the new collection.
03 / Decisions & approach
Shared collections with partition keys
Collections are shared by model and dimension, while tenants stay isolated by partition key.
Data migration, not a setting change
Model replacement became an explicit prepare → re-embed → verify → apply workflow.
Final apply gate
The service keeps using the old collection until the new one passes verification.
04 / System flow
Embedding migration flow
-
Prepare
-
Migrate
-
Verify
-
Apply
-
Observe
05 / Outcome
- Physical collection growth no longer scales with every customer and file.
- Operators can control progress and failures while replacing a model without downtime.
An embedding-model replacement is a data migration with retry and consistency requirements, not a config deployment.