When you search or query a collection, the data needs to be available to the query layer. In Milvus (and therefore DODIL VBase), that means the collection must be loaded into memory.

Think of it like this:

• Loaded = the collection is on your desk (fast to access).
• Released = the collection is back on the shelf (saves memory, but you can’t work with it until you load it again).

Why this matters

Search and query are memory-intensive. If you keep everything loaded forever, RAM usage grows and performance can degrade.

A good default policy:

• Load the collections you actively search/query.
• Release collections that are inactive (e.g., nightly jobs, rarely used datasets, old experiments).

Important: index requirement in DODIL

In DODIL VBase, loading a collection may fail if the collection does not have an index built for its vector field(s).

If you see an error like index not found / no index:

1. Create the index for the vector field.
2. Wait for index build to complete.
3. Load the collection again.

Why? Loading is used to prepare the collection for fast search. Without an index, the system can’t prepare the search-ready layout.

Load a collection

Use load_collection() when you’re about to search or query.

# Load the collection into memory so it is ready for search/query
vbase.load_collection(
    collection_name="my_collection",
)

Check the load state

You can verify whether it is loaded:

state = vbase.get_load_state(
    collection_name="my_collection",
)
 
print(state)
# Example output (format may vary by backend):
# {"state": "Loaded"}

Release a collection

Use release_collection() to free memory when you’re done.

# Release the collection from memory
vbase.release_collection(
    collection_name="my_collection",
)
 
state = vbase.get_load_state(
    collection_name="my_collection",
)
print(state)
# Example output:
# {"state": "NotLoad"}

When should I load vs release?

Load when:

• Your service is about to run search / hybrid search / query.
• You have a “hot” collection that is accessed frequently.

Release when:

• The collection is used rarely (saving RAM is more valuable than low-latency access).
• You run batch jobs and want to free memory after the job finishes.
• You are about to change something that affects the loaded state (for example, some index-related changes). In general: release first, then apply the change, then load again.

Common issues

“Index not found” or “index not enabled”

This means the collection does not have a usable vector index. Create the index first, then retry load_collection().

“Collection not loaded” when searching

If a search/query call fails saying the collection isn’t loaded, call load_collection() first.

Timeouts

Large collections can take time to load. If you have timeouts enabled in your client, increase the timeout or load during startup/warm-up.

Practical tip: warm-up strategy

For production services, it’s common to:

• Load critical collections on startup.
• Periodically check load state.
• Release inactive collections on a schedule.

That gives you predictable latency without wasting memory.