Содержание
Коротко
Сравнения vector DB часто сводятся к recall@k и latency. На Dev.to акцент другой: что ломается, когда RAG-сервис уходит из Jupyter в production — клиенты, установка, версии API.
Что произошло
Обзор пяти стеков с фокусом на архитектуру клиента, стабильность релизов и миграции:
| Библиотека | Сильная сторона | Риск в проде |
|---|---|---|
| ChromaDB | Быстрый прототип, embedded | Packaging, не distributed-first |
| Pinecone | Managed, без ops | Интернет обязателен, version churn |
| Qdrant | Local → prod без смены API | Баланс для команд с self-host |
| Weaviate | Hybrid search | Сложные миграции схемы |
| (пятый в оригинале) | См. источник | Зависит от workload |
Падения чаще от client/server mismatch, а не от «медленного HNSW».
Почему это важно
В ноутбуке Chroma «просто работает». В Docker/K8s всплывают: другой процесс embedded DB, конфликты зависимостей, смена major API Pinecone, неожиданные breaking changes в SDK.
Для full-stack разработчика выбор vector store — это контракт на годы, не pip install на демо.
На практике
- Прототип на embedded — ок; перед продом явно выбрать hosted vs self-hosted.
- Зафиксировать версии клиента в lockfile; читать changelog SDK, не только модели.
- Прогнать один и тот же ingestion pipeline на staging с production-like сетью.
- Для hybrid (keyword + vector) — заранее сравнить Weaviate/Qdrant, не только «самый быстрый бенчмарк».
- План миграции схемы и re-index — до первого релиза, не после.
Итог
«Лучшая» vector DB — та, у которой клиент и деплой совпадают с вашей архитектурой. Метрики поиска важны вторым эшелоном после стабильности поставки и API.