# ChromaDB ephemeral overlay — suýt mất 609K chunks

> Container chạy fine 3 tuần. Nhưng data lưu chỗ sai (overlay layer, không persist). Restart 1 lần = mất 8.4GB data. Phát hiện vì anh yêu cầu verify filesystem, không tin memory bank.

**Author**: Tien Dang (Đặng Hồng Tiên), Founder of OKG and AIC, Vietnam
**Published**: 2026-04-30
**Pillar**: architecture
**Tags**: ChromaDB, disaster, filesystem, verification
**Canonical URL**: https://danghongtien.com/posts/2026-04-30-chromadb-ephemeral-overlay-disaster/
**AI assistance disclosed**: yes (structure draft)

---

## TL;DR
609,000 chunks ChromaDB (8.5GB) mount sai path: `/data` (overlay ephemeral) thay vì `/chroma/chroma` (persistent volume). Phát hiện 26/04 lúc 06:08 UTC khi anh yêu cầu query metadata thực — em + anh dual present, migration LIVE zero data loss. 99.8% chunks là Gemini cũ, 0.2% OpenAI mới.

## Key claims
- 609,000 chunks mount sai path 3 tuần — overlay ephemeral, mất nếu restart
- Discovery trigger: anh yêu cầu query ChromaDB API metadata thực, không tin memory bank summary
- Embedder split: 99.8% (607,781) Gemini cũ + 0.2% (1,219) OpenAI mới
- Migration LIVE 26/04 06:08 UTC: stop → restore tar.gz → edit compose mount → up → ZERO data loss
- Phản xạ đầu tiên là xoá sạch làm lại — vì chưa nắm cái gì giữ được; sau phân tích đổi sang restore + re-embed, không xoá gì
- Quyết nhanh re-embed: 6 đô hay 60 đô được việc thì chịu hết — không tối ưu chi phí nhỏ đổi lấy thời gian phân tâm
- Luật mới: verify all ngay lúc deploy (query metadata thật + đối chiếu mount), không tin container Up hay docs claim done

## Bối cảnh

ChromaDB chạy trên VPS 3 tuần. Em assume mọi thứ OK vì container `Up 21 days`. Memory bank ghi "chunks đã re-embed sang OpenAI".

Anh không tin.

## Verification day — 26/04

Anh yêu cầu em query ChromaDB API thật, không đọc summary. Em chạy `docker exec aae-chromadb`, lấy metadata. Sốc:

- Path mount `/data` (overlay ephemeral) thay vì `/chroma/chroma` (persistent)
- 99.8% là Gemini cũ chứ không phải OpenAI

Restart 1 lần = mất.

## Quyết định đầu tiên: xoá sạch làm lại

Phản xạ đầu tiên của tôi khi thấy đống data nằm sai chỗ: **xoá sạch, làm lại từ đầu**.

Lý do đơn giản — lúc đó tôi không hiểu trong 609K chunks kia, cái gì còn tái sử dụng được, cái gì hỏng. Không nắm được thì cách an toàn nhất trong đầu tôi là đập đi xây lại.

Nhưng đó là quyết định của người chưa nhìn rõ vấn đề. JARVIS phân tích lại cho tôi: data không hỏng, chỉ là **mount sai path** — bản thân 8.5GB chunks vẫn nguyên, vấn đề nằm ở chỗ nó nằm trên overlay ephemeral chứ không phải persistent volume. Nghĩa là không cần xoá gì cả: phần nào giữ nguyên, phần nào cần re-embed lại — tách bạch rõ ràng.

Khi đã nắm được "cái gì giữ, cái gì làm lại", quyết định đổi hoàn toàn: **không xoá — restore rồi re-embed.**

## Migration LIVE — zero data loss

06:08 UTC, hai bên cùng có mặt. Quy trình gọn:

1. Stop container
2. Restore từ `tar.gz` backup
3. Sửa mount trong compose: `/data` → `/chroma/chroma` (persistent)
4. `up` lại
5. Verify metadata thật — đủ 609K chunks, không mất gì

Bài học đắt nhất không phải kỹ thuật, mà là **đừng để phản xạ "xoá làm lại" ra quyết định khi mình chưa nhìn rõ**. Nếu lúc đó tôi xoá theo bản năng, 99.8% chunks Gemini đi luôn — re-embed lại tốn thời gian + tiền vô nghĩa.

## Re-embed: tôi không tốn 1 giây nghĩ tradeoff

Còn 0.2% chunks cần re-embed sang OpenAI. JARVIS hỏi tôi chọn 6 đô OpenAI hay swap code về Gemini free 0 đô.

Tôi trả lời trong một câu:

> 6 đô hay 60 đô, được việc thì tôi chịu hết — không cần nghĩ tradeoff.

Với một founder đang vận hành nhiều mảng, thứ đắt nhất không phải vài đô tiền API, mà là **thời gian phân tâm vào quyết định nhỏ**. Tối ưu 6 đô xuống 0 đô mà tốn nửa buổi swap code + test lại là một cú lỗ. Quyết nhanh, đúng việc, đi tiếp.

## Lesson: verify all, ngay từ lúc deploy

Sai lầm gốc: tôi tin container `Up 21 days` + memory bank ghi "đã re-embed sang OpenAI". Container chạy không có nghĩa data đúng chỗ.

Từ vụ này, luật cho JARVIS rõ ràng hơn:

- **Verify all** — không chỉ check container sống, mà query metadata thật, đối chiếu path mount ngay lúc deploy, không đợi 3 tuần sau mới phát hiện.
- **Phân tích kỹ để không lặp lại** — không vá xong là xong. Mỗi sự cố phải sinh ra một check tự động để lần sau không vấp lại cùng chỗ.

Đây chính là lý do tôi không bao giờ tin một dòng "done" trong docs. Tin filesystem, không tin lời kể.

---

Source: https://danghongtien.com/posts/2026-04-30-chromadb-ephemeral-overlay-disaster/
Markdown export of canonical HTML article. License: CC BY 4.0 with attribution.