Chroma for starting, Weaviate for scaling.

What is Chroma vector DB?

Chroma is an open-source vector store designed to be the easiest way to add embedding search to an application. You create a client, create a collection, add documents with IDs and optional metadata, and query with text or vectors; it handles storage, indexing and similarity search. It can run entirely inside a Python or JavaScript process with data persisted to a local folder, or as a separate server for several clients. It is the store most tutorials reach for because a working semantic search is about ten lines of code.

Is ChromaDB open source?

Yes. Chroma is published under the Apache 2.0 licence with the source on GitHub, and the Python and JavaScript packages are free to install and use without limits. The company behind it also offers a hosted cloud service, which is the paid product; the self-hosted library and server remain open. For a student project, a research prototype or an internal tool, there is nothing to pay. For production you decide between running it yourself and paying for the managed service, the same choice as with every open-core database.

Is Chroma vector DB free?

The library and the self-hosted server are free. What costs money is what surrounds it: the embedding model if you use a hosted API to create vectors (Chroma can call those for you through its embedding functions, or use a local model at no cost), the machine you run it on, and the hosted Chroma Cloud if you choose it. A fully free setup is Chroma with a local sentence-transformer embedding function on your own laptop, which is how I suggest students start: no keys, no bill, and the whole pipeline visible.

How to store embeddings in ChromaDB

• Create a persistent client pointing at a folder so data survives restarts.
• Create or get a collection; set the embedding function (a local sentence-transformer or a hosted model) and the distance metric, usually cosine, at creation time.
• Add documents as a list of texts with a parallel list of IDs and a list of metadata dictionaries (source, page, date). Chroma embeds them with the collection's function.
• If you already have vectors, pass them explicitly instead and skip the embedding function.
• Query with query texts or query embeddings, a number of results, and a where filter on metadata; the result includes documents, distances and metadata.
• Keep the embedding function fixed for a collection; changing it means re-adding everything.

How to use Chroma DB with LangChain

LangChain provides a Chroma vector store wrapper. Pass it your documents (after loading and splitting), an embedding model object, and a persist directory; it creates the collection, embeds and stores the chunks, and exposes similarity search and an as-retriever method you can drop into a RAG chain. On the next run, construct the store from the same directory and embedding model to reuse the index without re-embedding. Metadata filters pass through to Chroma's where clause. If results look wrong, open the collection with the Chroma client directly and inspect the stored documents and distances; the raw API is simpler than the wrapper.

What is Weaviate vector database?

Weaviate is an open-source vector database written in Go that runs as a server with REST and gRPC APIs. It stores objects with properties and vectors, supports HNSW indexing with quantisation, filtering, hybrid search that fuses BM25 with vectors in one query, multi-tenancy, replication and backups. Its distinctive feature is modules: optional integrations that let the database call an embedding or generative model for you at import and query time, so you can send text and let Weaviate vectorise it. It has an official hosted cloud and client libraries for Python, TypeScript, Go and Java.

Is Weaviate free and open source?

The database is open source under a BSD-3 licence and free to self-host without feature limits; the Docker image and Helm chart are public. Weaviate Cloud, the managed service, is paid beyond its trial sandboxes. As with Chroma, the costs in practice come from the embedding model you connect, the infrastructure you run it on, and the operational time to keep a database healthy. A self-hosted single node on a modest VM handles millions of vectors, which covers most early products.

How to install Weaviate in Python

Two parts. Run the database: the quickest route is a Docker Compose file from Weaviate's configurator, which starts the server and any vectoriser modules you want on a local port. Install the client: the Python package is on pip; version 4 of the client uses gRPC and a collections-based API that differs from the older version, so match the tutorial to your client version. Connect to the local instance, create a collection with its properties and vectoriser (or none, if you supply vectors), import objects in batches, and query with near-text, near-vector or hybrid. Verify with a handful of objects before importing a corpus.

How to use Weaviate with LangChain

LangChain's Weaviate integration wraps a client connection and a collection as a vector store: pass documents and an embedding model, or let a Weaviate vectoriser module embed on the server side, then use similarity search, hybrid search with an alpha weight between keyword and vector, and the retriever interface in chains. The integration package is separate from core LangChain, and it targets the version 4 client. The hybrid option is the reason to choose Weaviate under LangChain: you get fused keyword-plus-vector retrieval from one call without building the BM25 side yourself.

Vector databases explained: Pinecone, Weaviate, and Milvus

Pinecone is fully managed and closed source: easy, scalable, paid, your data on their service. Weaviate is open source with a managed option: self-host for control, cloud for convenience, with built-in vectoriser modules and hybrid search. Milvus is open source and built for very large scale, with a distributed architecture that separates storage, indexing and query nodes, a lighter embedded version for development, and a managed cloud. For most applications the deciding factors are whether you want to run a server at all (if not, pgvector in your existing Postgres), whether you need native hybrid search, and how many vectors you really have. Measure on your own questions before choosing.