Weaviate Vector Database: Hybrid Search, Multi-Tenancy, Modules, and Deployment Options

Weaviate is an open-source vector database that stores objects together with their vector embeddings and supports semantic, keyword, and hybrid search, filtering, multi-tenancy, and retrieval-augmented generation. It can be self-hosted with Docker or Kubernetes, or used as a managed service through Weaviate Cloud. New to vector databases? Start with what is a vector database.

Core concepts

• Collections group objects with a defined set of properties, similar to tables.
• Objects hold properties (text, numbers, dates) plus one or more vectors. Named vectors let one object have several embeddings, for example one for the title and one for the body.
• Vectorizer modules can generate embeddings automatically through providers or local models. Alternatively, you bring your own vectors.
• Generative modules can pass retrieved results to an LLM to produce RAG answers inside the query.
• Multi-tenancy creates a separate shard per tenant within a collection.

Hybrid search in Weaviate

Hybrid search runs a BM25 keyword search and a vector search, then fuses the results. The alpha parameter controls the balance: 1 is pure vector search, 0 is pure keyword search, and values in between combine both. Hybrid search helps with names, codes, and jargon that embeddings alone can miss. See vector vs. keyword vs. hybrid search.

Python example (v4 client)

import weaviate

client = weaviate.connect_to_local()  # or connect to Weaviate Cloud with an API key

try:
    articles = client.collections.get("Article")
    response = articles.query.hybrid(
        query="reset two-factor authentication",
        alpha=0.5,
        limit=5,
    )
    for obj in response.objects:
        print(obj.properties["title"])
finally:
    client.close()

Client APIs evolve between versions, so check the Weaviate documentation for your client version, including how to define collections and vectorizers.

Deployment options

When to choose Weaviate

• You want hybrid search without stitching together separate keyword and vector engines.
• You run a SaaS product and need efficient per-tenant isolation.
• You prefer open source and the option to self-host in your own cloud for data residency.
• You like having embedding and generative model integrations available inside the database.

Compare it with alternatives in our vector database comparison, or read our guides to Qdrant and Pinecone.

Designing collections and properties

In Weaviate, data is organized into collections, each with a set of properties, similar to a table with columns. Each object in a collection can have one or more vectors. Design collections around how you will query: a Document collection might store chunk text, title, source URL, document type, language, updated date, and access groups as properties. Define properties explicitly rather than relying on automatic schema detection in production, so data types are correct and filtering behaves predictably. Mark properties you will filter or sort on appropriately, and choose tokenization settings for text properties used in keyword search, because tokenization affects how BM25 matches terms such as product codes and hyphenated words.

Vectorizer modules or bring your own vectors?

Weaviate can generate embeddings automatically using vectorizer modules that call embedding providers or locally hosted models when objects are added and when queries are run. This simplifies development, because you send text and Weaviate handles vectors. Alternatively, you can compute embeddings in your own pipeline and supply them directly, which gives full control over models, batching, retries, and costs. Many production teams start with a module for speed, then move to bring-your-own vectors if they need tighter control. Whichever you choose, record the model and version for each collection, and use the same model for documents and queries.

Tuning hybrid search

Hybrid search combines BM25 keyword relevance with vector similarity. The alpha parameter controls the balance: values near 0 favor keyword matching, values near 1 favor vector similarity, and values in between blend the two. Weaviate also lets you choose how scores are fused, for example ranked fusion or relative score fusion. There is no universal best setting. Build a test set of real queries and measure recall at different alpha values. Queries with exact identifiers, names, or error codes usually benefit from more keyword weight, while natural language questions benefit from more vector weight. Some applications adjust alpha per query type.

Multi-tenancy

Weaviate's native multi-tenancy feature creates a separate shard per tenant within a collection. Each tenant's data is isolated, queries automatically target one tenant, and tenants can be added, deactivated, or deleted efficiently, which is ideal for SaaS products with many customers. Inactive tenants can be offloaded to reduce resource usage and reactivated when needed. Your application must still determine the tenant from the authenticated user on the server and pass it with every request.

Compression and index options

Memory is often the largest cost of running a vector database. Weaviate supports several index types, including HNSW for fast approximate search, flat indexes for small collections, and a dynamic option that starts flat and switches to HNSW as data grows. It also supports vector compression such as product quantization and binary or scalar quantization, which reduce memory usage substantially with a modest effect on recall, often recovered by rescoring top results with full vectors. Test compression settings on your evaluation set to find the right balance between cost and quality.

Generative search and RAG with Weaviate

Weaviate offers generative modules that can pass retrieved objects to a language model and return a generated answer in the same query. This is convenient for prototypes and simple RAG applications. For production systems that need custom prompts, citation validation, guardrails, conversation history, or fine-grained cost control, many teams prefer to retrieve with Weaviate and handle generation in their own application layer. Either way, measure retrieval recall and answer faithfulness separately, so you know whether problems come from search or generation.

Operating Weaviate in production

• Replication: configure a replication factor greater than one for high availability, and understand the consistency settings for reads and writes.
• Backups: use Weaviate's backup modules to store backups in object storage, and test restores regularly.
• Resource planning: estimate memory from vector count, dimensions, and compression, and monitor usage as data grows.
• Upgrades: follow release notes, test upgrades in staging, and keep client libraries in step with server versions.
• Security: enable authentication and authorization, use TLS, restrict network access, and manage API keys in a secrets manager.
• Monitoring: export metrics to Prometheus or your monitoring platform, and alert on latency, errors, and memory pressure.

Weaviate Cloud handles much of this for you; self-hosting on Kubernetes gives more control at the cost of operational effort.

Example: hybrid product search for a parts supplier

An industrial parts supplier struggles with search because customers type a mix of part numbers, brand names, and descriptions such as "stainless hex bolt for outdoor use". The team loads its catalogue into a Weaviate collection with properties for part number, brand, category, specifications, and description, using tokenization suited to part numbers. Hybrid search with a moderate alpha matches exact part numbers through BM25 while understanding descriptive queries through vectors. Filters restrict results to in-stock items in the customer's region. Measured on a set of real search logs, the share of searches where customers click a result in the top five improves noticeably, and fewer customers contact support to find parts.

Common Weaviate mistakes

• Relying on auto-schema in production, which can create inconsistent property types.
• Ignoring tokenization for fields like codes and identifiers, weakening keyword matches.
• Using a single alpha value for every query without testing.
• Running a single node for a production system that needs high availability.
• Skipping backup restore tests.
• Mismatched client and server versions after upgrades.
• Enforcing tenant separation only in the front end.

Weaviate compared with alternatives

Weaviate stands out for built-in hybrid search, a schema-based data model, native multi-tenancy, and modules that integrate embedding and generative models. Qdrant is often chosen for very efficient filtering and quantization, Pinecone for a fully managed serverless experience without operations, and Chroma for the simplest developer experience in prototypes. PostgreSQL with pgvector suits smaller collections that live alongside relational data. Benchmark the options on your own data and queries, especially if hybrid search quality and multi-tenancy are important to your use case.

Summary

Weaviate is a strong choice when you need hybrid keyword and vector search, a structured data model, and multi-tenancy in one open-source database that can run in the cloud or on your own infrastructure. Design collections and tokenization carefully, tune hybrid search with real queries, use compression to manage memory, and operate it with replication, backups, and monitoring. Read our vector database comparison for a side-by-side view, our hybrid search guide for retrieval strategy, and our vector database development guide for production architecture.

Getting started checklist

1. Choose Weaviate Cloud or self-hosting based on your operational capacity and data residency needs.
2. Define collections and properties explicitly, including data types and tokenization for text fields.
3. Decide between a vectorizer module and bring-your-own vectors, and record the model version.
4. Enable multi-tenancy if you serve multiple customers, and design how tenants are created and removed.
5. Load a representative sample of data and build a test set of real queries.
6. Tune hybrid search alpha and fusion settings using the test set.
7. Evaluate compression options to manage memory cost.
8. Configure authentication, TLS, replication, backups, and monitoring before production traffic.

Evaluating Weaviate on your data

Run a focused proof of concept before committing. Load a realistic sample, ideally at least tens of thousands of objects with the metadata you will filter on, and measure recall at k, mean reciprocal rank, latency under concurrency, ingestion speed, and memory usage with and without compression. Compare pure vector, pure keyword, and hybrid queries, and test multi-tenant workloads if relevant. These measurements will tell you quickly whether Weaviate fits your requirements and how to configure it.

Typical Weaviate use cases

Teams commonly use Weaviate for retrieval-augmented generation over company documents, semantic and hybrid product search for e-commerce and parts catalogues, support ticket and knowledge base search, recommendation features based on similar items, and multi-tenant SaaS assistants where each customer's data must stay isolated. It is also used for multimodal search with image and text embeddings through the appropriate modules. In each case, the combination of keyword and vector search in a single query is often the deciding advantage, because real users mix exact terms with natural language descriptions. If your queries are purely semantic and your scale is modest, simpler options may be enough; if they mix exact identifiers and descriptions, Weaviate's hybrid search is a strong fit worth testing early.

Like any database decision, the right Weaviate configuration comes from measurement rather than defaults. Start with a representative dataset and real queries, adjust collections, tokenization, hybrid weighting, and compression based on results, and keep your evaluation set as a permanent part of the project so every later change can be checked quickly and safely before it reaches users.

That discipline turns a promising prototype into a dependable search system that users trust and that the team can keep improving with confidence.

Start small, test with real queries, and scale deliberately as usage grows.

Good search is built through iteration, not configuration alone.

Weaviate development with Vertex Cyber Tech

We deploy and integrate Weaviate for RAG and search, including Kubernetes deployments, ingestion pipelines, and evaluation. See our vector database capabilities and AI/ML services, or book a consultation.

Sources and further reading

• Weaviate documentation
• Weaviate on GitHub
• Weaviate: Hybrid search