Looking for the RagLeap platform? This page documents the open-source pip install ragleap-vectorstores library. For the hosted business platform (AI Office, WhatsApp/Voice bots, billing), see docs.ragleap.com instead.

12 / 12 tests passing · live-verified against real infrastructure

ragleap-vectorstores

Pluggable vector backends beyond ragleap-rag core's six — install only the client SDK you actually need, not the whole ecosystem.

0.1.0

PyPI version

Tests passing

Backend implemented

Install

Each backend's real client SDK is an optional extra — installing the bare package alone pulls in no heavy dependencies beyond ragleap-rag itself.

pip install ragleap-vectorstores[chroma]

Quick start

database_url= is still required even when using Chroma for vectors — ragleap-rag's conversation memory is always Postgres-backed regardless of which vector_backend is chosen; only vector storage moves.

from ragleap_vectorstores import ChromaBackend
from ragleap import RagLeap, ProviderConfig, EmbeddingConfig

backend = ChromaBackend(persist_directory="./chroma_data")

rag = RagLeap(
    database_url="postgresql://...",   # still required — conversation memory
    vector_backend=backend,             # vectors go to Chroma instead
    primary=ProviderConfig(provider="gemini", api_key="..."),
    embedder=EmbeddingConfig(provider="gemini", api_key="..."),
)
rag.init_schema()
rag.ingest("report.pdf")
answer = rag.ask("What were Q3's key findings?")

Full public API surface

Confirmed via direct source reading, not inspect().

from ragleap_vectorstores import VectorBackend, ChromaBackend, __version__

ChromaBackend — implements VectorBackend

ChromaBackend(persist_directory, collection_name="ragleap")

Embedded/local via chromadb's PersistentClient — no server required. persist_directory is required; both Chroma's on-disk index and a small document-registry SQLite sidecar live there.

init_schema(dimensions)

Creates or opens the Chroma collection (cosine similarity space).

insert_document / insert_chunk

Chroma persists chunk text and metadata natively — no sidecar needed for chunks. The sidecar is only for the document registry (filename, upload time), since Chroma has no native parent-document concept.

search_dense(embedding, top_k, metadata_filter=None)

Cosine similarity search. Multi-key metadata_filters are automatically wrapped in Chroma's required $and form.

search_sparse / search_hybrid

Not natively supported — honestly falls back to the VectorBackend default (empty / dense-only) rather than claiming unimplemented capability.

supports_sparse()

Returns False — see Known limitations below.

list_documents / delete_document / get_document_filename

Operate against the local SQLite document registry.

Known limitations

Drawn from live testing against the real installed chromadb==1.5.9 package this session — not from documentation alone.

No native sparse/keyword search. supports_sparse() honestly reports False — chromadb has no native BM25/keyword surface as of 1.5.9, so search_hybrid() falls back to dense-only.
where= filters need exactly one top-level operator. A plain multi-key metadata filter dict raises ValueError against real chromadb — ChromaBackend wraps multi-key filters in $and automatically, but this is a real constraint worth knowing if you're debugging filter behavior directly against chromadb.
database_url= is still required. Conversation memory is always Postgres-backed in ragleap-rag, regardless of which vector backend is chosen — Chroma only replaces vector storage.
Dependency footprint. chromadb's own transitive dependencies are non-trivial (kubernetes client libs, OpenTelemetry, uvicorn extras) — correctly gated behind the optional [chroma] extra, but worth knowing before installing into a size-sensitive environment.