Если вам нужно быстро поднять векторную базу для RAG-прототипа, у вас по сути два разных пути. Chroma DB — это pip install и рабочая база через пять строк кода без единого сервера. Weaviate — это уже настоящая распределенная система со схемой, GraphQL-запросами и встроенной генерацией эмбеддингов. В статье разберем архитектуру обеих баз, честно сравним их с Qdrant и покажем, какую выбрать под конкретный сценарий.
Chroma DB — встраиваемая векторная база без сервера, идеальна для локальных прототипов и Jupyter-ноутбуков. Weaviate — распределенная база со схемой, GraphQL и гибридным поиском из коробки. Обе проще Qdrant в старте, но Weaviate ближе к продакшену. В статье — архитектура, цены на сентябрь 2026 и таблица выбора.
Что вообще делает векторная база данных
Векторная база хранит эмбеддинги, строит по ним индекс для быстрого поиска и возвращает ближайших соседей к запросу. Разница между базами — в том, как именно устроены индекс и фильтрация.
На 10 тысячах векторов подойдет любой брутфорс-перебор. На 10 миллионах при 1536 измерениях (стандарт для OpenAI-эмбеддингов) прямой перебор занимает секунды на запрос, и это уже неюзабельно. Поэтому все три базы, о которых пойдет речь, используют приближенный поиск ближайших соседей — чаще всего алгоритм HNSW.
HNSW — это многослойный граф. Поиск стартует на разреженном верхнем слое, спускается к нужному региону, а на нижнем плотном слое уточняет результат. У параметра recall есть цена: чем выше точность, тем выше задержка ответа. Это компромисс, который встроен в саму архитектуру, и от него никуда не деться ни в Chroma, ни в Weaviate, ни в Qdrant.
Weaviate GraphQL или REST что использовать
Weaviate работает через GraphQL-интерфейс вместо привычного REST API. Это дает гибкие запросы с фильтрами и вложенными связями в одном вызове, но требует привыкания, если ваша команда раньше работала только с REST.
GraphQL-запрос в Weaviate позволяет за один вызов получить объект, применить фильтр по свойствам и запросить связанные объекты — то, что в REST потребовало бы нескольких запросов подряд. Для команд, которые уже работают с GraphQL в других частях стека, это снижает порог входа почти до нуля.
Но есть нюанс. Weaviate хранит объекты и векторы вместе: у каждого объекта есть свойства, инвертированный индекс для keyword-поиска и HNSW-индекс для векторного поиска в одной системе. Это не случайное архитектурное решение — именно оно и позволяет Weaviate делать гибридный поиск, о котором дальше.
Максим: «Мы в VibeCoderz тестировали три векторные базы для одного из внутренних RAG-пайплайнов. Weaviate заняла на настройку схемы часа два, зато потом гибридный поиск сразу поймал точные совпадения по артикулам инструментов, которые обычный векторный поиск пропускал».
Встроенная генерация эмбеддингов зачем она нужна
Weaviate умеет сама считать эмбеддинги через модули-векторайзеры прямо внутри базы, без отдельного вызова API модели эмбеддингов. Это упрощает пайплайн, но привязывает вас к конкретному провайдеру эмбеддингов на уровне конфигурации.
Обычно процесс выглядит так: вызвать API модели эмбеддингов, получить вектор, загрузить его в базу отдельным шагом. Weaviate убирает средний шаг. Настраиваете модуль-векторайзер один раз, а дальше просто загружаете текст — база сама считает embedding и сохраняет его. Меньше кода, меньше точек отказа в пайплайне.
Обратная сторона: вы завязываетесь на конкретный векторайзер на уровне схемы. Смена модели эмбеддингов означает пересчет всей коллекции заново, и это стоит учитывать заранее, если вы планируете экспериментировать с разными моделями.
Что такое Chroma DB и чем она отличается от обычной СУБД
Chroma DB — минималистичная встраиваемая база: HNSW-индекс плюс SQLite для метаданных, обернутые в Python-дружелюбный API. В простейшем случае работает прямо в процессе приложения, без отдельного сервера вообще.
Установка — pip install chromadb. Дальше пять строк кода, и у вас есть работающее векторное хранилище. Для локальных экспериментов, jupyter-ноутбуков и небольших прототипов это ровно то, что нужно: не нужно поднимать инфраструктуру, настраивать сеть, следить за отдельным процессом.
Именно с Chroma DB стартует подавляющее большинство RAG-проектов, и не просто так. Простота здесь работает как суперсила на этапе прототипирования. Но у той же простоты есть предел масштабирования, к которому мы вернемся ниже.
Фильтрация в Chroma DB и Weaviate в чем разница
Weaviate использует single-stage фильтрацию через инвертированный индекс на основе roaring bitmap — фильтр и поиск идут одновременно внутри обхода графа. Chroma исторически применяла post-filtering: сначала находит похожие векторы, потом отбрасывает несовпавшие по фильтру.
Разница звучит технически, но на практике бьет по продакшену жестко. Реальные RAG-запросы почти никогда не выглядят как «найди похожие векторы» — обычно это «найди похожие векторы, где user_id равен такому-то и дата документа позже января». Если фильтр селективный (скажем, отбирает 1% документов), а база сначала достает top-K векторов и только потом фильтрует, можно получить ноль релевантных результатов после отсева.
Weaviate решает это иначе: инвертированный индекс пересекается с обходом HNSW-графа прямо во время поиска, поэтому селективные фильтры остаются быстрыми без потери recall. У Chroma новые распределенные версии эту слабость подтягивают, но исторически это была её самая уязвимая точка. Если ваш продакшен-сценарий строится вокруг фильтров по пользователю, дате или тенанту, разница в архитектуре фильтрации перевешивает разницу в скорости на unfiltered-запросах.
Weaviate или Chroma что выбрать для прототипа
Для чистого прототипа без сложной фильтрации Chroma DB быстрее в старте: ноль инфраструктуры, пять строк кода. Weaviate оправдана, когда прототип сразу включает гибридный поиск или сложные фильтры по метаданным — тогда проще сразу строить на правильной архитектуре.
| Параметр | Chroma DB | Weaviate |
|---|---|---|
| Старт | pip install, без сервера | Docker-контейнер или облако |
| Индекс | HNSW + SQLite | HNSW + инвертированный индекс |
| Фильтрация | Post-filtering (историческая слабость) | Single-stage, лучшая в классе |
| Гибридный поиск | Ограничен | BM25 + вектор, встроен |
| Генерация эмбеддингов | Нет из коробки | Встроенные модули-векторайзеры |
| Квантизация | Ограничена, float32 по умолчанию | Расширенная: product, binary с re-ranking |
| Цена (сентябрь 2026) | Self-host бесплатно, облако до $250/мес | Self-host бесплатно, облако $45–400/мес |
| Лучше всего для | Локальный прототип, ноутбуки | Гибридный поиск, продакшен со схемой |
Данные по ценам актуальны на сентябрь 2026 и могут измениться — Chroma уже дважды меняла тарифы в апреле 2026, снизив верхний план с $500 до $250 в месяц.
Гибридный поиск в Weaviate когда он реально нужен
Гибридный поиск объединяет BM25 (keyword) и векторный поиск в одном запросе через reciprocal rank fusion. Это сигнатурная фича Weaviate — критична для документов с точными терминами вроде артикулов или названий функций, которые чистый векторный поиск пропускает.
Чистый векторный поиск отлично находит смысловые совпадения, но проваливается на точных совпадениях — модель артикула, код ошибки, редкое имя функции просто не имеют устойчивого семантического соседства. BM25 наоборот: ловит точные термины, но упускает смысловые связи. Weaviate запускает оба поиска одновременно и сливает результаты через reciprocal rank fusion.
Для каталогов продуктов, технической документации или RAG над кодовой базой это реальное преимущество, а не маркетинговая формулировка. Chroma DB подобного из коробки не предлагает — нужно собирать гибридную схему вручную поверх базового API.
Chroma DB или Qdrant для быстрого локального теста
Для чистого локального прототипа без production-нагрузки Chroma DB стартует быстрее Qdrant: не нужен даже Docker. Qdrant при этом дает более серьезную фильтрацию и легче переносится в продакшен без переписывания логики.
Qdrant написан на Rust и архитектурно ближе к Weaviate: тоже single-stage фильтрация через payload-индекс, но легче и быстрее на чистых векторных нагрузках. У Qdrant нет встроенного гибридного BM25-поиска в том виде, что у Weaviate, зато self-host обычно обходится дешевле при сравнимой производительности.
Лиза: «Прикинь, для нашего внутреннего поиска по конспектам мы сначала подняли Chroma просто чтобы проверить гипотезу за вечер. Работало. Но когда пошли реальные фильтры по категориям, стало понятно, что дальше нужен либо Weaviate, либо Qdrant — разница именно в фильтрации, не в скорости поиска как таковой».
Квантизация в Weaviate и Chroma DB кому она нужна раньше
Weaviate поддерживает продвинутую квантизацию — product и binary с re-ranking, что экономит память в разы. Chroma по умолчанию хранит векторы как float32, поддержка квантизации там новее и менее зрелая.
Один эмбеддинг на 1536 измерений занимает около 6 КБ при float32. На 100 миллионах векторов это уже 600 ГБ оперативной памяти — дорого при любом хостинге. Scalar-квантизация до int8 сокращает объем в 4 раза почти без потерь recall. Binary-квантизация режет память в 32 раза, но требует re-ranking, чтобы вернуть точность.
Если ваш прототип с самого начала рассчитан на миллионы записей, зрелая квантизация Weaviate экономит реальные деньги на инфраструктуре. Для прототипа на тысячах или десятках тысяч векторов эта разница пока не критична — там выигрывает простота Chroma.
Кому подходит Weaviate а кому Chroma DB
Chroma DB подходит для прототипа, локальной разработки и небольших нагрузок без сложной фильтрации. Weaviate — выбор, когда сразу нужен гибридный поиск, схема и путь в продакшен без миграции на другую базу.
- Берите Chroma DB, если: вы тестируете гипотезу, работаете в ноутбуке, у вас нет времени поднимать инфраструктуру, объем данных — тысячи или десятки тысяч векторов.
- Берите Weaviate, если: нужен гибридный поиск по точным терминам, фильтры селективные и по нескольким полям, вы планируете расти в продакшен без переписывания архитектуры.
- Берите Qdrant вместо обеих, если: нужна максимальная скорость на чистых векторных запросах без гибридного поиска и хочется дешевый self-host.
Подробнее про установку и первый поиск в Qdrant — в отдельном гайде Qdrant: установка и первый поиск на Python. А общее сравнение трех главных игроков рынка — в статье Векторные базы: Pinecone vs Qdrant vs pgvector.
Глоссарий
- HNSW (Hierarchical Navigable Small World) — алгоритм приближенного поиска ближайших соседей через многослойный граф.
- Embedding (эмбеддинг) — числовой вектор, представляющий смысл текста или изображения.
- Recall@10 — метрика: сколько из истинных 10 ближайших соседей попало в реальную топ-10 выдачу.
- Post-filtering — сначала поиск похожих векторов, потом отсев по фильтру.
- Single-stage filtering — фильтр и поиск применяются одновременно внутри обхода индекса.
- Гибридный поиск (hybrid search) — объединение keyword-поиска (BM25) и векторного поиска в одном запросе.
- Квантизация — сжатие векторов для экономии памяти ценой части точности.
Часто задаваемые вопросы
Можно ли использовать Chroma DB в продакшене?
Да, через Chroma Cloud или распределенную open-source версию, но исторически архитектура заточена под single-node сценарии. Для высокой нагрузки с селективной фильтрацией лучше присмотреться к Weaviate или Qdrant.
Нужен ли Docker для запуска Weaviate?
Для локальной разработки да, обычно через Docker-контейнер. Есть управляемое облако Weaviate Cloud, где Docker не нужен вообще — от $45 в месяц на тарифе Flex.
Chroma DB бесплатна?
Open-source версия полностью бесплатна под лицензией Apache 2.0. Managed Chroma Cloud — от бесплатного стартового уровня до $250 в месяц на тарифе Team по состоянию на сентябрь 2026.
Поддерживает ли Chroma DB гибридный поиск?
Из коробки — ограниченно. Базовый гибридный поиск можно собрать вручную поверх API, но нативной BM25+vector fusion, как в Weaviate, там нет.
Что проще для новичка без опыта в бэкенде: Weaviate или Chroma?
Chroma DB проще на порядок для первого запуска — не нужна схема, не нужен отдельный сервер. Weaviate требует понимания схемы классов и свойств с самого начала.
Стоит ли сразу выбирать Weaviate, если планирую расти в продакшен?
Разумный подход — начать с Chroma для проверки гипотезы за один вечер, а после превышения примерно миллиона векторов или устойчивой нагрузки оценить реальную селективность фильтров в проекте и при необходимости мигрировать на Weaviate или Qdrant.
Есть ли встроенная генерация эмбеддингов в Chroma DB?
Нет, эмбеддинги нужно считать отдельным вызовом модели и передавать в базу. Weaviate умеет считать их сама через модули-векторайзеры.
Если разбираетесь, какая векторная база подойдет под ваш проект, посмотрите каталог обзоров AI-инструментов на vibecoderz.ru/ide или запишитесь на консультацию к Максиму — разберем архитектуру конкретно под вашу задачу.
Обновлено: сентябрь 2026