Weaviate: Collections, Hybrid Search, and Tenant Scope

Weaviate

Weaviate organizes objects, properties, and vectors into searchable collections. Define the embedding contract, searchable text, filter fields, and tenant boundary before tuning relevance. The application still decides which authenticated actor may select a tenant and return an object.

Hybrid retrieval can combine keyword and vector signals, but configuration alone does not demonstrate better answers. Use judged queries, restrictive filters, updates, and tenant-specific cases to determine whether the complete retrieval path works.

TL;DR

Choose explicit property and vectorization contracts for each collection.
Keep tenant selection tied to trusted application identity.
Apply required filters consistently across retrieval and mutation paths.
Evaluate hybrid ranking with representative relevance judgments.
Check server compatibility, ingestion, backup, and recovery separately from offline SDK objects.

Quick Example

This complete Python fixture uses Weaviate client 4.24.1 to construct property objects and a filter without contacting a server. Its separate tenant gate is an invented application rule, not Weaviate authentication.

No collection, embedding, hybrid query, tenant shard, or access policy was created. A real integration must prove the server receives the intended tenant and filter and that an alternate path cannot bypass the application’s policy.

Core Concepts

Collection and vectorization

Specify property types and the vector representation. Decide whether an integration vectorizes data or your application supplies vectors. Record model/version, preprocessing, dimensions and named-vector selection. Equal dimensions do not make unrelated embeddings comparable.

Tenant and authorization

Weaviate documents tenant-separated shards within multi-tenant collections. That storage boundary does not establish that a caller is entitled to select a particular tenant. Keep tenant activation/lifecycle, application identity, and administrative access in the design. Multi-tenancy

Hybrid retrieval

Hybrid search combines lexical and vector retrieval signals using the configured method. Filters, candidate limits and target vectors affect which records can be ranked. Treat a score as a retrieval signal, not proof that an answer is true or access is permitted. Hybrid search

Evaluate relevance and isolation together

Prepare a small known-answer dataset with at least two fictional tenants, visible/hidden records, exact terminology and paraphrases. Make expected permitted candidates unambiguous before assessing ranking quality. Then expand to a representative judged workload.

Compare keyword-only, vector-only and hybrid candidates using the same data and access constraints. Keep retrieval quality separate from answer generation quality. A generated answer can be wrong even when retrieval found the right paragraph, and a fluent answer can conceal missing relevant evidence.

Include small tenants and selective filters. A broad unfiltered demonstration may conceal empty results, poor candidate coverage or inconsistent tenant propagation in a real application. Record which configuration changed and what would reverse the choice.

Operate the ingestion and recovery path

Track accepted objects, failed batches, embedding failures, schema mismatch and update visibility. Give each ingestion operation a stable identity and define repeat behavior. An acknowledged client call is only one observation in the path from source material to searchable result.

Review deployment-specific transport, authentication, network exposure, tenancy controls, resource limits and administrative authority. Test actual clients and service versions together. The offline fixture cannot establish server admission, distributed behavior or workload capacity.

Choose the documented backup and restore mechanism for the deployment and rehearse it into an isolated target. Check collection configuration, tenant availability, object/vector integrity, required access rules and representative query results. Retain recovered data age and application routing decisions. An archive existing is not a demonstrated retrieval recovery.

Treat embedding-provider credentials, source text and query logs as data with their own access and retention requirements. Avoid storing full user prompts or documents simply because a troubleshooting dashboard offers the field.

Best Practices

Version the search contract

Keep properties, vectorization, ranking and required filters together in review. Plan a migration rather than silently mixing incompatible representations.

Test all data-returning paths

Check search, object lookup, export and administrative interfaces exposed by the application. One correctly scoped query does not cover the rest automatically.

Preserve realistic quality evidence

Use expected candidates and judged queries, including failures and empty outcomes. No universal hybrid weight or performance winner follows from the fixture.

Common Mistakes

Bad: Allowing an untrusted request to choose arbitrary tenant context.

Correct: Derive allowed context from trusted identity and enforce the decision on every relevant path.

Bad: Calling offline SDK construction a search test.

Correct: Run actual server queries and evaluate candidates, filters, visibility and access separately.

Bad: Tuning hybrid scores without a relevance baseline.

Correct: Compare the same judged queries and record quality, latency and resource tradeoffs.

FAQ

What needs a running Weaviate server to test?

Everything beyond request construction: indexing, search results, tenant isolation, authorization, and performance. Local SDK objects only show how your code builds requests and selects tenants.

Does multi-tenancy replace authorization?

No. The application and service policy must still determine who may select or administer a tenant.

How should hybrid settings be chosen?

Use representative judged queries and consistent access constraints; keep changes and reversal conditions in the evaluation record.