chromem-go: an embeddable Go vector database for RAG without a server

The problem: RAG in Go usually means running a second service

A Go service that wants retrieval augmented generation has to put embeddings somewhere and search them. The usual answer is a separate vector database process, which brings a deployment unit, a network hop, a client library and its transitive dependencies. The README frames chromem-go as the SQLite answer to that: an embeddable database you add to your app instead of running PostgreSQL or MySQL next to it. The stated goal is to add RAG and similar embeddings-based features to a Go app without a separate database. The intended audience is Go developers building question answering, text and code search, recommendation, classification or clustering features who are willing to keep the corpus in process. The README is explicit that chromem-go is not a client for Chroma and not a reimplementation of it; it is its own database that borrows Chroma's interface shape.

How the in-memory store and embedding providers fit together

The README describes a database object created with chromem.NewDB() and collections created on it, with GetCollection, GetOrCreateCollection and DeleteCollection as siblings of CreateCollection. There is no client-server split, which is why the type is called DB rather than client. Documents enter through collection.Add, carrying an ID, an optional embedding, optional metadata and the document text. Embeddings can be supplied by you or produced by an embedding model, and the README lists out-of-the-box support for multiple embedding providers: the repository files include embed_cohere.go, embed_ollama.go, embed_openai.go, embed_vertex.go and embed_compat.go, so Cohere, Ollama, OpenAI, Vertex and an OpenAI-compatible endpoint are the provider surfaces visible in the layout. Retrieval happens through collection.Query, which takes a query text, a result count and two optional filters: a metadata equality filter and a document filter using the $contains operator. The repository also contains a wasm/ directory and an examples/webassembly/ example, so a browser target is part of the layout, though the README does not describe its constraints. Persistence is optional and lives in persistence.go, separate from the in-memory core.

Installing chromem-go and running a first query

The module path is github.com/philippgille/chromem-go and go.mod declares go 1.21, so a Go 1.21 or newer toolchain is the floor. Fetch it with go get, then build the smallest useful program: create a database, create a collection, add two documents, and query for the closer one. The README's own equivalent example passes nil for embeddings to let the library handle embedding automatically, and the query call below mirrors that shape.

go get github.com/philippgille/chromem-go

package main

import (
	"context"
	"fmt"

	"github.com/philippgille/chromem-go"
)

func main() {
	db := chromem.NewDB()
	collection, _ := db.CreateCollection("all-my-documents", nil, nil)
	_ = collection.Add(context.Background(),
		[]string{"doc1", "doc2"},
		nil,
		[]map[string]string{{"source": "notion"}, {"source": "google-docs"}},
		[]string{"This is document1", "This is document2"},
	)
	results, _ := collection.Query(context.Background(), "This is a query document", 2, nil, nil)
	fmt.Println(results)
}

What you should see is the two added documents ranked by similarity to the query string, with the nearer document first. The README notes that AddConcurrently exists for multi-threaded insertion, so a bulk load does not have to be sequential. If you want a working end-to-end reference rather than a skeleton, the examples directory ships minimal, rag-wikipedia-ollama, s3-export-import, semantic-search-arxiv-openai and webassembly, each with its own README.

Scale, API stability and the missing delete path

The README states the focus is not scale in the millions of documents, and gives query timings on a mid-range 2020 Intel laptop CPU: 1,000 documents in 0.3 ms and 100,000 documents in 40 ms. Those are the project's own figures, not independent measurements, and they describe query latency rather than ingestion throughput or memory footprint. Since the store is in-memory, the real ceiling is how much embedding data you can hold in the process, and the README offers no memory guidance. The second limitation is stability: the README warns the project is in beta, under heavy construction, and may introduce breaking changes in releases before v1.0.0, with changes documented in CHANGELOG.md. The third is interface coverage. The README says the project started with four core methods and intentionally does not want to cover 100% of Chroma's API surface, and the code comment in its own example says update and delete will be added in the future. If your application needs to mutate or remove documents after insertion, that is a gap you should confirm against the current Godoc before designing around it.

chromem-go compared with running Chroma itself

The obvious alternative is Chroma, whose Python interface inspired chromem-go's. The difference is deployment shape rather than feature parity. Chroma runs as a separate service you talk to over a client, and the README's own framing is that chromem-go exists so you do not have to run a separate database, the same way SQLite removes the PostgreSQL process. That trade is real in both directions: you lose the ability to scale the store independently of your application, to share one index across multiple services, and to use the parts of Chroma's API that chromem-go deliberately omits. You gain a single binary, no network hop, and zero third-party dependencies, which the README lists as a feature. For a Go service where the corpus is bounded and the index is private to that process, the embedded model removes an operational component. For a platform where several services query the same index, or where the index outgrows one machine's memory, the separate service is the better fit and chromem-go is the wrong tool.

Licence and the cost of tracking a pre-1.0 API

chromem-go is licensed under MPL-2.0, a file-level copyleft licence. The practical consequence for most users is that modifications to chromem-go's own source files must be made available under the same licence, while your application code that merely imports the library is not forced into it. That is a general description of the licence family, not legal advice; if you plan to fork or patch the library and ship it, have your own counsel read the LICENSE file. The upgrade cost is the more immediate concern. With releases at v0.5.0, v0.6.0 and v0.7.0 and the README's warning about breaking changes before v1.0.0, pinning a specific version and reading CHANGELOG.md before each bump is the realistic workflow. The dependency surface is small, since the module declares no third-party requirements in go.mod, so an upgrade is unlikely to ripple through your dependency graph. The last push to the repository was on 2026-09-06, and the most recent tagged release listed is v0.7.0 from 2024-09-01, so the release cadence and the commit cadence are not the same thing.

Editorial conclusion

Adopt chromem-go when your corpus fits in memory and you want RAG or semantic search inside a single Go binary without operating a database server. Do not adopt it if you need millions of documents, a network endpoint, or a stable API surface, because the README states the project is in beta and may introduce breaking changes before v1.0.0. Before committing, verify the current interface in the Godoc at pkg.go.dev and read the CHANGELOG, since the README itself says the four core methods have grown over time.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. philippgille/chromem-go on GitHub
4. README
5. Releases