Milvus vs Chroma: which vector database fits your production workload
A retrieval prototype built on Chroma is often the fastest route to a working demo, but production raises different questions: how large the collections will grow, how many tenants share them, who will operate the stack, and whether access rules must be enforced inside the database itself. Milvus fits when those answers point to a distributed deployment, larger collections, role-based access control and GPU indexing, and when your team can operate Kubernetes along with the services Milvus depends on. Chroma fits when the workload is in-memory or single-node development, when the footprint must stay small, or when a simple four-function API is the priority. Neither answer is permanent, so write the answers down before the prototype hardens.
Start with four questions. First, what is the expected collection size and growth rate, and does it stay within what one node handles comfortably? Second, how many tenants need isolation, and do they need separate databases, collections, partitions or partition keys? Third, who will run the stack after launch: a platform team that already runs etcd, object storage and Kubernetes, or a small application team that needs a single process? Fourth, must access control be enforced by the database, not by your application? Milvus documents authentication, TLS and role-based access control, and Chroma's local mode may lack features present in its distributed system, so confirm each control against the specific Chroma mode you plan to run. Ask both vendors to show these controls working in your environment.
Plan the migration path before you need it. Keep embedding models, chunking logic and metadata schemas in your own code rather than in the store's client calls, so a move between the two databases changes the storage layer and not the pipeline. Benchmark recall and latency on a copy of your real data at your target size, since results on a laptop rarely predict cluster behavior. Check which Milvus releases and Chroma releases you intend to pin, and confirm the upgrade path for each before committing.
Which platform fits each scenario
This table names the better fit for five common situations and the condition that decides it. Read each row against your own constraints: the deciding condition matters more than the default choice, and the items marked for verification need confirmation in your environment before you commit.
| Scenario | Better fit | Deciding condition and supporting facts |
|---|---|---|
| Notebook or proof of concept | Chroma | Chroma's in-memory client for prototyping needs only pip install chromadb or npm install chromadb, with no separate service. Milvus Lite is the closest Milvus option for a notebook, and it fits when the prototype is expected to move to Milvus later. |
| Single internal application, one team | Chroma (single-node) or Milvus Standalone | Choose Chroma when the team wants the client-server mode started with chroma run --path and a small footprint. Choose Milvus Standalone when the collection is expected to grow, since it runs on one machine without the distributed dependencies. Confirm whether local Chroma has the features your application needs, because the Chroma overview says it may temporarily lack features available in the distributed system. |
| Multi-tenant SaaS feature | Milvus | Milvus supports multi-tenancy at database, collection, partition or partition key level, which gives you more isolation choices than a single-node store. Confirm the tenant isolation model, query performance per tenant and how Chroma's distributed mode handles tenancy for your scale before deciding. |
| Regulated deployment needing authentication and TLS in the database | Milvus | Milvus implements authentication, TLS encryption and role-based access control in the database itself. Chroma's open source overview does not list these controls in the supplied facts, so confirm them directly with the Chroma project and in your own tests before assuming they meet your requirements. |
| Team with no Kubernetes skills | Chroma, or Milvus Standalone for a single machine | Chroma's single-node mode avoids a cluster entirely. Milvus Distributed is Kubernetes-native and depends on etcd, object storage and a write-ahead log, so it is a poor fit without Kubernetes operators. Milvus Standalone runs on one machine and is the Milvus option to evaluate for these teams, with the scaling limits confirmed against your data volume. |
How Milvus and Chroma are built and deployed
Milvus and Chroma both run as open-source vector stores, but they are assembled very differently. Milvus splits compute, metadata and storage into separate services, while Chroma's two modes use different storage subsystems, so the patching, backup and on-call work follows from those choices.
Milvus Lite, Standalone and Distributed
Milvus offers three deployment modes: Milvus Lite as an embedded Python library for prototypes, Standalone on a single machine, and Distributed as a Kubernetes-native cluster. Moving between them changes the operating model, not just the scale. Check which mode your team will run in production before writing application code, because data handling and client assumptions can differ across modes. Confirm the upgrade path between modes with the Milvus documentation before you commit.
Disaggregated compute and storage
Milvus separates stateless proxies, a coordinator layer and worker nodes from storage. Metadata lives in etcd, and object storage is MinIO, S3 or Azure Blob. Patching a Distributed deployment means rolling several component types, and backups must cover etcd and object storage together. Ask who on your team owns each of these services and how restores are tested end to end.
Write-ahead log choice
Milvus uses Woodpecker, Kafka or Pulsar as its write-ahead log. This choice decides whether you run an extra messaging system in production and who on-call pages when ingestion lags. If your organization already operates Kafka or Pulsar with support contracts, the operational load may be lower. Confirm which log option is supported for your chosen mode and version with the Milvus docs.
Chroma distributed and single-node modes
Chroma has two deployment modes, distributed Chroma and single-node local Chroma, and they rely on different storage subsystems. Local Chroma is simpler to stand up, but it may temporarily lack features available in the distributed system. Verify feature parity for your required filters, search modes and access controls before a prototype becomes a production dependency.
Patching, backups and on-call impact
A single-node Chroma process is a smaller surface to patch and back up, but a crash or disk loss hits the whole store at once. Milvus Distributed spreads that risk across components yet multiplies the moving parts your on-call team must recognize. Write down the backup target, restore test frequency and upgrade window for each option. Ask both vendors for their supported upgrade paths between releases.
Milvus vs Chroma side by side on search, access and APIs
This table compares Milvus and Chroma on licensing, index choice, search types, security controls, API surface and managed options. Read each row as a question to answer for your own workload, and treat any cell that says to confirm as a gap to close before you commit.
| Capability | Milvus | Chroma |
|---|---|---|
| License | Apache-2.0, under the LF AI and Data Foundation with Zilliz as primary contributor | Apache 2.0, with the project stating it is and will always remain open source |
| Index options | HNSW, IVF, FLAT, SCANN and DiskANN indexes are listed in the README | Index types for local and distributed modes are not covered in supplied facts; confirm in the Chroma documentation |
| Hybrid and full-text search | BM25 full-text search, sparse vectors and hybrid dense plus sparse search | Chroma Cloud is described as offering vector, hybrid and full-text search; confirm which of these the self-hosted modes support |
| Quantization and memory | Quantization and memory-mapped files are listed in the README | Quantization support is not covered in supplied facts; confirm before sizing memory |
| GPU indexing | GPU indexing with NVIDIA CAGRA | Not covered in supplied facts; confirm in the Chroma documentation |
| Metadata and content filters | Scalar filtering and multi-tenancy at database, collection, partition or partition key level | Metadata and document-content filters on queries, shown in the core API |
| Authentication, TLS and RBAC | Implements authentication, TLS encryption and role-based access control | Access control in local and distributed modes is not covered in supplied facts; confirm in the Chroma documentation |
| API surface | Client SDKs over a server-side cluster; the README documents deployment modes, not a four-function core API | Four-function core API where Chroma handles tokenization, embedding and indexing automatically; installs with pip or npm |
| Managed options | Zilliz Cloud offers Serverless, Dedicated and bring-your-own-cloud options | Chroma Cloud is a hosted serverless search service running the same open-source distributed system |
What the licenses and paid options cover for each
Milvus is Apache-2.0 licensed and operates under the LF AI and Data Foundation, with Zilliz as its primary contributor. The project maintains two active release lines, v3.0.3 published on October 14, 2026 and v2.6.25 published on September 29, 2026, so you choose which line to standardize on before you deploy. Zilliz sells a managed version of Milvus, and that service is separate from the open-source project you can run yourself.
- License scope: Apache-2.0 grants you the right to use, modify and redistribute the code. It does not include someone to run your clusters, patch them or answer incident calls.
- Governance: The LF AI and Data Foundation hosts the project, while Zilliz is the primary contributor. Ask how the foundation and the contributor share roadmap and security response.
- Release lines: Two lines are active at once. Confirm which line receives security fixes and for how long before you pick one.
- Zilliz Cloud options: Zilliz offers Serverless, Dedicated and bring-your-own-cloud choices. Bring-your-own-cloud keeps data in your account, which is the option most relevant to regulated teams.
- Support terms: Commercial support, response times and upgrade assistance are set by Zilliz or a third-party provider under their own contracts. Confirm each term in writing.
Before you commit, ask Zilliz and any support provider which Milvus line they cover, what the support scope includes and whether upgrades between lines are part of the contract.
Chroma is licensed under Apache 2.0, and its open-source overview states that the database is and will always remain open source. Chroma Cloud runs the same open-source distributed system as the self-hosted product, so the managed service and the code you can run yourself are closely related. The README also states that Chroma Cloud signups receive $5 of free credits, which is a trial allowance rather than a long-term operating budget.
- License scope: Apache 2.0 covers the code. Running, patching and upgrading the database in your own environment remains your responsibility.
- Stated commitment: The open-source overview says the project is and will remain open source. Treat this as the maintainer's statement and keep it in your vendor file.
- Managed parity: Chroma Cloud runs the same open-source distributed system, so you can prototype against the cloud service and later self-host with the same core design.
- Free credits: The README states $5 of free credits at signup. Confirm current credit terms and any usage limits on the Chroma site before you plan a trial.
- Local mode limits: The overview notes that single-node local Chroma may temporarily lack features available in the distributed system, so confirm feature parity for your mode.
Before you commit, ask Chroma which support tiers exist for self-hosted deployments, what they cover and how they are priced, and confirm the Chroma Cloud terms for data location and retention.
An open-source license grants the right to use and change the software, but it does not transfer operational responsibility. For both platforms, the license covers the code, while your team or an implementation partner covers the infrastructure, upgrades, backups, security patching and any support contract. This tab explains what a license does not cover, so you can budget for the work the license leaves to you.
- Operations: Running either database in your own infrastructure means you own deployment, monitoring, capacity planning and incident response.
- Upgrades: Each project releases updates on its own schedule. Plan testing and rollback for every upgrade, including the Milvus release line choice.
- Support: Vendor support is a separate contract. Neither license obliges any party to answer your tickets or meet response targets.
- Managed services: A managed service shifts some operations to the vendor, but its terms, data location and exit path depend on the contract, not the open-source license.
- Who pays: Internal staff time, infrastructure, a managed subscription or an implementation partner's fixed-scope work are separate cost lines to compare.
Before you commit, ask each vendor for written support scope, response commitments, upgrade assistance and exit terms, and confirm them directly with the vendor rather than relying on this page.
What drives the running cost of Milvus and Chroma
The running cost of Milvus is mostly the cost of the services around it, while the running cost of Chroma is mostly the cost of the process and storage you give it. In a Milvus Distributed deployment, you pay for compute and memory for the stateless proxies, coordinators and worker nodes, plus object storage in MinIO, S3 or Azure Blob, plus the etcd metadata store and the write-ahead log service you choose (Woodpecker, Kafka or Pulsar). Each of those needs capacity, monitoring and backups. A Chroma deployment in single-node mode has fewer moving parts, so its infrastructure line is smaller, but the staff time to back up and upgrade the store does not disappear. Ask your team to price each component separately rather than accepting a single line for "vector database."
Some costs are one-time and some recur. One-time work includes integration with your embedding pipeline, collection and schema design, index selection and the migration of any prototype data. Recurring work includes hosting, backups and restore tests, on-call coverage, and upgrades. Milvus publishes two active release lines, v3.0.3 (published October 14, 2026) and v2.6.25 (published September 29, 2026), so the upgrade path is a planning decision with its own testing cost, not a routine patch. Chroma's distributed mode carries a similar operational profile, and its single-node mode carries less, but a team that moves from local Chroma to distributed Chroma should budget for a second round of migration and testing. Collection size, replica count and tenant count are the main drivers. More vectors raise memory and storage use, more replicas raise compute and storage, and more tenants (database, collection, partition or partition key) raise the isolation and access work each one needs. When you request a quote, ask for the deployment mode, the full list of services in scope (including etcd, the write-ahead log, object storage and any Kubernetes components), the upgrade path between Milvus release lines and who tests it, and who carries the pager after go-live. If you are considering Zilliz Cloud or Chroma Cloud, ask for the managed-service fee separately from your own hosting, and confirm which data-location and access controls apply to each option. Any quote that does not state these items cannot be compared with another.
How to move a Chroma prototype to Milvus
This sequence takes a working Chroma prototype and rebuilds it as a Milvus deployment with a defined schema, tenancy model, access controls and a tested cutover. Embeddings and metadata usually carry over, while indexes, client code and access rules are rebuilt for the target system.
Inventory the Chroma collections and queries
The application owner and the engineer who built the prototype list every Chroma collection, the embedding model used to create its vectors, the metadata fields stored with each record, and the document-content and metadata filters the application sends at query time. Record which Chroma client calls are used and where the embedding function runs. The step is done when the inventory fits on one page and every filter the application uses appears in it, so nothing is discovered during cutover.
Define the Milvus schema and deployment mode
The engineering team writes the Milvus collection schema: primary key, vector field with its dimension, scalar fields that mirror the Chroma metadata, and a sparse or text field if the prototype relied on full-text matching. They choose an index type from those Milvus supports, such as HNSW, IVF, FLAT, SCANN or DiskANN, and select the deployment mode. Milvus Lite suits development, while Standalone or Distributed fits production, and Distributed brings etcd, object storage and a message queue. The step is done when the schema and mode are written in a design note that the platform team has reviewed.
Decide the tenancy model
Before loading data, the team decides how tenants and sensitive data are separated. Milvus offers multi-tenancy at database, collection, partition or partition key level, and the choice depends on the number of tenants, how much isolation each needs and how queries will filter by tenant. The owner of data classification signs off on the choice. The step is done when each tenant or data class has a named isolation level and the query pattern for it has been tested against a small sample.
Re-embed or export the vectors
Engineers either export the stored vectors and metadata from Chroma or re-embed the source documents with the same embedding model. Exporting keeps vectors identical to the prototype, which makes recall comparisons cleaner. Re-embedding is needed when the model changes or the source documents are the only trusted copy. The team checks vector dimensions and counts against the Chroma collection, and the step is done when record counts and a sample of vectors match between the two systems.
Rebuild filters, access rules and transport security
Engineers rewrite each Chroma metadata and document-content filter as a Milvus boolean filter expression and test it against the loaded data. They then configure authentication, TLS encryption and role-based access control in Milvus, mapping roles to the collections, databases or partitions defined earlier. The security owner reviews the role grants. The step is done when every filter returns the same results as the Chroma version on the sample set and a test identity with a restricted role cannot read a collection it should not reach.
Run parallel queries to compare recall and latency
For a representative set of production-like queries, the team sends each query to Chroma and Milvus and compares the returned identifiers, recall against a known relevant set and response times. Differences usually come from index parameters or distance metrics, so the team adjusts those before accepting the results. The step is done when the team has a written comparison showing recall and latency for each query class and has signed off on any accepted differences.
Cut over and retire the prototype path
The application switches its client code from the Chroma client to the Milvus client, using the connection settings and credentials issued in the access step. The team keeps the Chroma data for a fallback period agreed in advance, monitors errors and query results, and then removes the Chroma dependency from the application. The step is done when production traffic runs on Milvus, the rollback path has been tested, and the Chroma service is shut down or archived under the agreed retention rule.
Where Milvus and Chroma projects usually run long
Milvus Distributed carries most of the effort in its supporting services, not in the vector database itself. A production cluster means standing up Kubernetes, an etcd deployment for metadata, object storage (MinIO, S3 or Azure Blob) and the write-ahead log you choose from Woodpecker, Kafka or Pulsar. Once those run, the team still has to tune index choices, partitions and partition keys, and access roles, then set up backup and restore routines for both metadata and object storage. Plan for upgrades too, since Milvus maintains two release lines, v3.0.3 and v2.6.25 as of the Milvus releases page, and a move between them is its own project. Confirm with your platform team which of these services they already operate and support before you size the work.
Chroma is small on one node and grows when you move to distributed mode. Local Chroma started with chroma run --path or the in-memory client is quick to stand up, and the four-function core API keeps application code short. The effort shows up when you need the distributed system, because it relies on a different storage subsystem and local Chroma may temporarily lack features that the distributed system has. Before committing, run your required queries, metadata filters and hybrid searches against the deployment mode you will actually run in production, and record any gaps. Ask the Chroma maintainers to confirm parity for each feature on that list, since the open source overview is the authority on which features differ.
Four delays recur on both sides, and most of them start before any software is installed. First, data-location rules are often unclear, so a team builds a cluster and then learns that embeddings or source documents may not leave a given region or account. Second, an embedding model change forces full re-indexing of every collection, so pick the model and its dimensions before loading data. Third, tenancy is often decided late, and moving from a shared collection to per-tenant databases or partition keys after launch is expensive. Fourth, access control gets added after the pilot, when authentication, TLS and role-based access need to be designed in from the start. DeployOpen plans and implements these systems inside your own infrastructure under a written, fixed scope, so these decisions can be agreed and documented before the build begins.
What buyers ask before choosing Milvus or Chroma
How much more effort is Milvus Distributed than Chroma single-node?
Milvus Distributed is a much larger system to run than single-node Chroma, and most of the extra work sits in its dependencies rather than its vector API. Milvus Distributed runs as a Kubernetes-native cluster with stateless proxies, a coordinator and worker nodes. It also needs etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log such as Woodpecker, Kafka or Pulsar. Chroma single-node uses its own local storage subsystem and starts with chroma run --path. Each Milvus service you add must be sized, patched, monitored and backed up. Check the component list and upgrade path in the Milvus architecture overview and confirm sizing with your own load tests before you commit.
What drives the cost of running Milvus or Chroma yourself?
License fees are not the main cost driver, because both projects are Apache-2.0 licensed. The costs come from infrastructure, staff time and any outside help. For Milvus Distributed, the largest recurring items are compute for proxies and worker nodes, etcd, object storage capacity, the message queue and the Kubernetes capacity under them, plus monitoring and backup. For Chroma single-node, the main items are a host with enough memory and disk, storage growth and your backup routine. One-time costs include architecture, integration and hardening. Ongoing costs include upgrades and on-call time. In any quote, ask who pays for infrastructure, who operates it, which environments are included, and what upgrades cost each year. No cost figures are supplied for either product, so treat any number you see as something to verify against your own scope.
Can our team run Milvus without outside help?
Yes, if your team already runs Kubernetes, object storage and a message queue well and has an engineer who owns the cluster. If those skills are thin, plan for outside help from the start. Milvus Distributed adds etcd, object storage and a write-ahead log to the Milvus components, so the operating load is spread across several systems. Choose the deployment mode that matches the workload and use Milvus Lite for prototypes only. Before going live, write a runbook covering failover, backup restores and upgrades, and test a restore. Choose a release line deliberately, since Milvus maintains v3.0.3 and v2.6.25 side by side, and confirm the support expectations for each in the Milvus releases page. DeployOpen can plan, implement and support a self-hosted Milvus deployment under a fixed scope or retainer, if your team wants that help.
How long does moving a Chroma prototype to Milvus take?
No duration applies to every team, because the answer depends on scope. A prototype with one collection, a short list of metadata filters and a single user group is a different job from a multi-tenant service with audit requirements. Scope the move around the work that actually changes: mapping collections and metadata to Milvus schemas, confirming that the same embedding model is used so search results stay comparable, rebuilding filters with Milvus expressions, adding authentication and TLS, deploying the cluster, testing query behavior and planning cutover. As an illustration, a team with one collection may scope a small, well-defined move, while a team with several tenants and regulated data needs a longer and more detailed plan. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for a written scope before you plan any date.
What skills does a Milvus production cluster need from our team?
A production Milvus cluster needs Kubernetes operations, object storage administration, message queue operations and etcd care, and someone who can own security configuration. Milvus documents authentication, TLS encryption and role-based access control, so the team must configure and test each one. Expect to manage certificates, secrets, network policies, backups and monitoring. Single-node Chroma needs different skills: Linux host administration, Python or JavaScript service operations, local storage backup and network controls around the service. In both cases, the team needs routines for upgrades, restore tests and alerting. Ask any implementation partner to show how they hand over runbooks and who holds on-call responsibility after go-live. Check the project's own Milvus repository for current security features before you finalize your design.
Can Chroma enforce role-based access control?
The supplied material does not establish that Chroma provides role-based access control, so do not assume it does. Milvus documents authentication, TLS encryption and role-based access control in its README. For Chroma, confirm with the project's documentation for the exact version you plan to run. Ask specifically about authentication for the client-server mode, permissions per collection or tenant, audit logging, and whether local Chroma has the same controls as the distributed system. The Chroma open source overview notes that local Chroma may temporarily lack features available in the distributed system, so check local mode separately. If a control is missing, a common approach is to place an authenticating application layer in front of the store and test it, but that layer is your responsibility to design and maintain.
Does a managed service change where our vector data lives?
Yes, a managed service changes where the data is hosted, but it only helps if your data location rules allow it. Zilliz Cloud offers managed Milvus with Serverless, Dedicated and bring-your-own-cloud options, and Chroma Cloud is a hosted serverless search service that runs the same open-source distributed system. Bring-your-own-cloud keeps the infrastructure in your own cloud account, while the other options depend on the vendor's regions and contract terms. Before you decide, confirm in writing where vectors, metadata, logs, backups and replicas are stored, who can access them, how deletion works and which jurisdictions apply. Self-hosting keeps all of these inside your own infrastructure, which is the model DeployOpen works within, including your cloud accounts, data centers and air-gapped networks.
Can DeployOpen help us choose between Milvus and Chroma?
Yes, DeployOpen can help with the selection and with implementation of the option you choose. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. A selection review can produce a written scope that compares the workload, data location rules, access control needs and operating skills of your team. If you choose Milvus or Chroma, implementation follows the agreed scope. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen is not an official partner of either vendor.
How DeployOpen helps choose, implement or migrate
DeployOpen starts by working out whether your workload needs a distributed vector database or a lighter store that fits a prototype or single-node service. We then plan, implement, document and hand over the chosen setup inside your own cloud account, data center or air-gapped network, under a written scope.
How we scope
- Confirm the expected collection sizes, query patterns, tenancy model and data residency rules before recommending a deployment mode.
- Write down which Milvus deployment mode or Chroma mode fits, and what is out of scope, in the agreed statement of work.
- Agree deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
How we build
- Deploy the chosen store in your environment, including its storage, metadata and message queue dependencies where Milvus requires them.
- Configure authentication, TLS and role-based access control, and test tenant isolation against your own access model.
- Test search quality, filtering and hybrid queries on your data, and run security checks on the API and network exposure.
How we hand over
- Document the architecture, configuration, backup and restore steps, and the upgrade path for the version you run.
- Provide a migration plan if a Chroma prototype moves to Milvus, covering data export, re-indexing and client code changes.
- Walk your platform and security teams through operations so they can run the system without DeployOpen on call.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer for the vector store and its dependencies.
- Review new release lines and dependency changes before you upgrade, and document the impact on your deployment.
- Prepare the configuration and evidence your compliance assessors may ask for, while independent auditors issue any formal assessment.
