Schema and data format changes are a necessary evil of evolving software. We take changes seriously and make them infrequently and only when necessary.

Chroma's commitment is whenever schema or data format change, we will provide a seamless and easy-to-use migration tool to move to the new schema/format.

Specifically we will announce schema changes on:

• Discord (#migrations channel)
• Github (here)
• Email listserv Sign up

We will aim to provide:

• a description of the change and the rationale for the change.
• a CLI migration tool you can run
• a video walkthrough of using the tool

Migration Log#

v0.5.17#

We no longer support sending empty lists or dictionaries for metadata filtering, ID filtering, etc. For example,

is not supported. Instead, use:

v0.5.12#

The operators $ne (not equal) and $nin (not in) in where clauses have been updated:

• Previously: They only matched records that had the specified key.
• Now: They also match records that don't have the specified key at all.

In other words, $ne and $nin now match the complement set of records (the exact opposite) that $eq (equals) and $in (in) would match, respectively.

The $not_contains operator in the where_document clause has also been updated:

• Previously: It only matched records that had a document field.
• Now: It also matches records that don't have a document field at all.

In other words, $not_contains now matches the exact opposite set of records that $contains would match.

RateLimitingProvider is now deprecated and replaced by RateLimitEnforcer. This new interface allows you to wrap server calls with rate limiting logic. The default SimpleRateLimitEnforcer implementation allows all requests, but you can create custom implementations for more advanced rate limiting strategies.

v0.5.11#

The results returned by collection.get() is now ordered by internal ids. Whereas previously, the results were ordered by user provided ids, although this behavior was not explicitly documented. We would like to make the change because using user provided ids may not be ideal for performance in hosted Chroma, and we hope to propagate the change to local Chroma for consistency of behavior. In general, newer documents in Chroma has larger internal ids.

A subsequent change in behavior is limit and offset, which depends on the order of returned results. For example, if you have a collection named coll of documents with ids ["3", "2", "1", "0"] inserted in this order, then previously coll.get(limit=2, offset=2)["ids"] gives you ["2", "3"], while currently this will give you ["1", "0"].

We have also modified the behavior of client.get_or_create. Previously, if a collection already existed and the metadata argument was provided, the existing collection's metadata would be overwritten with the new values. This has now changed. If the collection already exists, get_or_create will simply return the existing collection with the specified name, and any additional arguments—including metadata—will be ignored.

Finally, the embeddings returned from collection.get(), collection.query(), and collection.peek() are now represented as 2-dimensional NumPy arrays instead of Python lists. When adding embeddings, you can still use either a Python list or a NumPy array. If your request returns multiple embeddings, the result will be a Python list containing 2-dimensional NumPy arrays. This change is part of our effort to enhance performance in Local Chroma by using NumPy arrays for internal representation of embeddings.

v0.5.6#

Chroma internally uses a write-ahead log. In all versions prior to v0.5.6, this log was never pruned. This resulted in the data directory being much larger than it needed to be, as well as the directory size not decreasing by the expected amount after deleting a collection.

In v0.5.6 the write-ahead log is pruned automatically. However, this is not enabled by default for existing databases. After upgrading, you should run chroma utils vacuum once to reduce your database size and enable continuous pruning. See the CLI reference for more details.

This does not need to be run regularly and does not need to be run on new databases created with v0.5.6 or later.

v0.5.1#

On the Python client, the max_batch_size property was removed. It wasn't previously documented, but if you were reading it, you should now use get_max_batch_size().

The first time this is run, it makes a HTTP request. We made this a method to make it more clear that it's potentially a blocking operation.

Auth overhaul - April 20, 2024#

If you are not using Chroma's built-in auth system, you do not need to take any action.

This release overhauls and simplifies our authentication and authorization systems. If you are you using Chroma's built-in auth system, you will need to update your configuration and any code you wrote to implement your own authentication or authorization providers. This change is mostly to pay down some of Chroma's technical debt and make future changes easier, but it also changes and simplifies user configuration. If you are not using Chroma's built-in auth system, you do not need to take any action.

Previously, Chroma's authentication and authorization relied on many objects with many configuration options, including:

• chroma_server_auth_provider
• chroma_server_auth_configuration_provider
• chroma_server_auth_credentials_provider
• chroma_client_auth_credentials_provider
• chroma_client_auth_protocol_adapter

and others.

We have consolidated these into three classes:

• ClientAuthProvider
• ServerAuthenticationProvider
• ServerAuthorizationProvider

ClientAuthProviders are now responsible for their own configuration and credential management. Credentials can be given to them with the chroma_client_auth_credentials setting. The value for chroma_client_auth_credentials depends on the ServerAuthenticationProvider; for TokenAuthenticationServerProvider it should just be the token, and for BasicAuthenticationServerProvider it should be username:password.

ServerAuthenticationProviders are responsible for turning a request's authorization information into a UserIdentity containing any information necessary to make an authorization decision. They are now responsible for their own configuration and credential management. Configured via the chroma_server_authn_credentials and chroma_server_authn_credentials_file settings.

ServerAuthorizationProviders are responsible for turning information about the request and the UserIdentity which issued the request into an authorization decision. Configured via the chroma_server_authz_config and chroma_server_authz_config_file settings.

Either _authn_credentials or authn_credentials_file can be set, never both. Same for authz_config and authz_config_file. The value of the config (or data in the config file) will depend on your authn and authz providers. See here for more information.

The two auth systems Chroma ships with are Basic and Token. We have a small migration guide for each.

Basic#

If you're using Token auth, your server configuration might look like:

Note: Only one of AUTH_CREDENTIALS and AUTH_CREDENTIALS_FILE can be set, but this guide shows how to migrate both.

And your corresponding client configation:

To migrate to the new server configuration, simply change it to:

New client configuration:

Token#

If you're using Token auth, your server configuration might look like:

Note: Only one of AUTH_CREDENTIALS and AUTH_CREDENTIALS_FILE can be set, but this guide shows how to migrate both.

And your corresponding client configation:

To migrate to the new server configuration, simply change it to:

New client configuration:

Reference of changed configuration values#

• Overall config
  • chroma_client_auth_token_transport_header: renamed to chroma_auth_token_transport_header.
  • chroma_server_auth_token_transport_header: renamed to chroma_auth_token_transport_header.
• Client config
  • chroma_client_auth_credentials_provider: deleted. Functionality is now in chroma_client_auth_provider.
  • chroma_client_auth_protocol_adapter: deleted. Functionality is now in chroma_client_auth_provider.
  • chroma_client_auth_credentials_file: deleted. Functionality is now in chroma_client_auth_credentials.
  • These changes also apply to the Typescript client.
• Server authn
  • chroma_server_auth_provider: Renamed to chroma_server_authn_provider.
  • chroma_server_auth_configuration_provider: deleted. Functionality is now in chroma_server_authn_provider.
  • chroma_server_auth_credentials_provider: deleted. Functionality is now in chroma_server_authn_provider.
  • chroma_server_auth_credentials_file: renamed to chroma_server_authn_credentials_file.
  • chroma_server_auth_credentials: renamed to chroma_server_authn_credentials.
  • chroma_server_auth_configuration_file: renamed to chroma_server_authn_configuration_file.
• Server authz
  • chroma_server_authz_ignore_paths: deleted. Functionality is now in chroma_server_auth_ignore_paths.

To see the full changes, you can read the PR or reach out to the Chroma team on Discord.

Migration to 0.4.16 - November 7, 2023#

This release adds support for multi-modal embeddings, with an accompanying change to the definitions of EmbeddingFunction. This change mainly affects users who have implemented their own EmbeddingFunction classes. If you are using Chroma's built-in embedding functions, you do not need to take any action.

EmbeddingFunction

Previously, EmbeddingFunctions were defined as:

After this update, EmbeddingFunctions are defined as:

The key differences are:

• EmbeddingFunction is now generic, and takes a type parameter D which is a subtype of Embeddable. This allows us to define EmbeddingFunctions which can embed multiple modalities.
• __call__ now takes a single argument, input, to support data of any type D. The texts argument has been removed.

Migration from >0.4.0 to 0.4.0 - July 17, 2023#

What's new in this version?

• New easy way to create clients
• Changed storage method
• .persist() removed, .reset() no longer on by default

New Clients

You can still also access the underlying .Client() method. If you want to turn off telemetry, all clients support custom settings:

New data layout

This version of Chroma drops duckdb and clickhouse in favor of sqlite for metadata storage. This means migrating data over. We have created a migration CLI utility to do this.

If you upgrade to 0.4.0 and try to access data stored in the old way, you will see this error message

You are using a deprecated configuration of Chroma. Please pip install chroma-migrate and run chroma-migrate to upgrade your configuration. See https://docs.trychroma.com/deployment/migration for more information or join our discord at https://discord.gg/8g5FESbj for help!

Here is how to install and use the CLI:

If you need any help with this migration, please reach out! We are on Discord ready to help.

Persist & Reset

.persist() was in the old version of Chroma because writes were only flushed when forced to. Chroma 0.4.0 saves all writes to disk instantly and so persist is no longer needed.

.reset(), which resets the entire database, used to by enabled-by-default which felt wrong. 0.4.0 has it disabled-by-default. You can enable it again by passing allow_reset=True to a Settings object. For example: