# Tenant states

Multi-tenant collections enable you to efficiently manage isolated subsets of data using the same schema and configuration. Weaviate supports the following tenant states:

| Tenant state     | CRUD & Queries | Vector Index | Inverted Index | Object Data | Time to Activate | Tenant description                         |
| ---------------- | -------------- | ------------ | -------------- | ----------- | ---------------- | ------------------------------------------ |
| Active (default) | **Yes**        | Hot/Warm     | Warm           | Warm        | None             | Available for use                          |
| Inactive         | **No**         | Warm         | Warm           | Warm        | Fast             | Not available for use, stored locally      |
| Offloaded        | **No**         | Cold         | Cold           | Cold        | Slow             | Not available for use, stored on the cloud |

A tenant status management strategy can help you to balance cost and performance. Here's why. An active tenant with an HNSW index uses _hot_ resources, which are the most expensive. At the other end of the spectrum, an offloaded tenant uses _cold_ resources, which are the least expensive.

:::callout{intent="info" title="Tenant state propagation"}
A tenant state change may take some time to propagate across a cluster, especially a multi-node cluster.

For example, data may not be immediately available after reactivating an offloaded tenant. Similarly, data may not be immediately unavailable after offloading a tenant. This is because the [tenant states are eventually consistent](../replication-architecture/consistency.md#tenant-states-and-data-objects), and the change must be propagated to all nodes in the cluster.
:::

### Tenant states and resource usage

_Hot_ tenants can be deactivated to _warm_ storage to reduce memory usage, and any tenant can be offloaded to _cold_ storage to reduce memory and disk usage. Conversely, any tenant can be reactivated when needed.

Therefore, consider a strategy of deactivating tenants that are not frequently accessed, and offloading tenants that are rarely accessed.

For example, imagine an e-commerce platform with separate tenants for each vendor. During a holiday sale, the tenant for a popular electronics vendor might be kept active for quick access, while tenants for seasonal vendors (e.g., Christmas decorations in July) could be offloaded to cold storage to save resources.

Understanding how tenant states interact with different index types is crucial for developing an effective resource management strategy. Let's explore this relationship in more detail.

### Tenant states and index types

Tenant states management strategies are tied to index types. This is because the index type determines the resources used by a tenant. For example, a tenant with an HNSW index type uses _hot_ resources, while a tenant with a flat index type uses _warm_ resources.

If a multi-tenant collection is configured with a dynamic index type, some tenants may be stored in _warm_ storage (flat index) and others in _hot_ storage (HNSW index). As a result, effectively managing tenants with HNSW indexes may have the most significant impact on resource usage.

We suggest following the following guidelines for selecting a tenant state:

```mermaid
flowchart LR
    %% Define nodes and connections
    subgraph tenantData ["Tenant Data Availability"]
        direction LR
        needNow{"Does the tenant data<br> need to be<br> available now?"}
        howQuick{"When it is needed,<br> how quickly does it<br> need to be available?"}

        needNow -->|Yes| active["Active"]
        needNow -->|No| howQuick
        howQuick -->|Quickly| inactive["Inactive"]
        howQuick -->|"Latency is acceptable"| offloaded["Offloaded"]
    end

    %% Style nodes
    style needNow fill:#ffffff,stroke:#B9C8DF,color:#130C49
    style howQuick fill:#ffffff,stroke:#B9C8DF,color:#130C49

    %% Terminal nodes
    style active fill:#ffffff,stroke:#61BD73,color:#130C49
    style inactive fill:#ffffff,stroke:#61BD73,color:#130C49
    style offloaded fill:#ffffff,stroke:#61BD73,color:#130C49

    %% Style subgraph
    style tenantData fill:#ffffff,stroke:#61BD73,stroke-width:2px,color:#130C49
```

If you are unsure which tenants can be made inactive or offloaded, consider a strategy of deactivating tenants that have not been accessed for a certain period of time. And offloading tenants that have not been accessed for a longer period of time.

## Hands-on

Here are some resources to implement hands-on tenant offloading in Weaviate.

### Configure tenant offloading

In order to use tenant offloading, you need to configure an offload module.

(See [How-to: Configure tenant offloading](../storage-and-backups/tenant-offloading.md))

### Update a tenant state

A tenant state can be switched between `active`, `inactive`, and `offloaded` at any time.

(See [How-to: Manage tenant states](../how-to-manage-collections/tenant-states.md) for instructions and code examples.)

### Auto-activate tenants

You can configure a collection to automatically activate (inactive and offloaded) tenants when they are accessed.

This can provide a balance between resource usage and performance.

(See [How-to: Auto-activate tenants](../how-to-manage-collections/tenant-states.md#automatically-activate-tenants) for instructions and code examples.)

## Questions and feedback

Have a question or feedback? Here's how to reach us.

::::card-grid
:::card{title="Community Forum" href="https://forum.weaviate.io/c/support" icon="messages-square"}
Ask questions and connect with other developers on our **Community forum**.
:::

:::card{title="Support" href="/guides/support-overview" icon="life-buoy"}
Weaviate Cloud user or customer? Find the right channel on the **Support page**.
:::
::::

## Related pages

- [Agents](./agents-index.md)
- [AI-assisted Weaviate code generation](./ai-assisted-vibe-coding-index.md)
- [APIs](./apis-index.md)
- [Authorization and authentication](./authorization-and-authentication-index.md)
- [Benchmarks](./benchmarks-index.md)
- [Best practices](./best-practices-index.md)
- [Client libraries](./clients-index.md)
- [Client Libraries / SDKs](./client-libraries-index.md)
- [Cloud](./cloud-index.md)
- [Cloud account management](./cloud-account-management-index.md)

# Agent Instructions

This portal answers questions programmatically. To receive a synthesized,
source-cited answer instead of crawling page by page, append the `?ask=`
query parameter to any page URL on this site:

    /guides/quickstart?ask=how+do+I+authenticate

Optional parameters:

- `&goal=<what-you-are-trying-to-do>` steers the answer toward your
  objective (e.g. `&goal=write+a+python+client`).
- `&version=<label>` scopes the answer to a mounted version when the
  portal publishes more than one.

The response is `text/markdown`: the answer followed by a `# Sources` list
of the portal pages it was grounded in. Status codes are the contract:

- `200` — the answer; `402` — the portal owner’s plan or answer credits are
  exhausted (surface this to your operator; do NOT retry); `429` — you are
  rate-limited; back off for the `Retry-After` seconds; `503` — the answer
  lane is temporarily unavailable; fall back to crawling the `.md` pages.

For the full corpus map read `llms.txt` at the site root; for the tool
surface (search + page fetch as MCP tools) see `/mcp`.