chromem-go

chromem-go is an open-source embeddable vector database for Go, created by philippgille and licensed under MPL-2.0. It lets Go applications add retrieval augmented generation (RAG) and other embeddings-based features without running a separate database server, much like SQLite is used instead of PostgreSQL or MySQL. The latest listed release is v0.7.0 (2024-09-01), and the README marks the project as beta with possible breaking changes before v1.0.0.

What It Is

chromem-go is a standalone vector database written in Go, with an interface inspired by Chroma. It is not a client for Chroma and not a reimplementation of it. It stores documents and their embeddings in memory, with optional persistence, and runs inside the host application process. Its stated focus is simplicity and performance for common use cases rather than scale to millions of documents.

How the Workflow Works

You create a DB, create a collection, and add documents with optional metadata. Embeddings can be supplied by you or generated by the library. Querying runs an exhaustive nearest-neighbor search using cosine similarity, with optional document filters ($contains, $not_contains) and exact-match metadata filters. For RAG, the retrieved content is then passed to an LLM alongside the question. Adding and querying documents are multithreaded using Go concurrency.

Embedding Providers and Storage

Hosted embedding providers supported out of the box are OpenAI (the default), Azure OpenAI, GCP Vertex AI, Cohere, Mistral, Jina and mixedbread.ai. Local options include Ollama, llmman and LocalAI, and a custom EmbeddingFunc can be implemented. Storage is in-memory, with optional immediate persistence as gob-encoded files that can be gzip-compressed. The whole DB can be exported or imported to a single file, optionally gzip-compressed and AES-GCM encrypted, and generic io.Writer/io.Reader methods allow plugging in blob storage such as S3.

Performance and Roadmap

The README reports benchmarks on a 2020 Intel laptop CPU: about 0.3 ms to query 1,000 documents and about 40 ms for 100,000 documents. Planned work listed includes SIMD dot products, approximate nearest neighbor indexes (HNSW, IVFFlat), $and/$or filter operators, additional storage formats and support for images and videos. An experimental WebAssembly binding exists.