Weaviate: AI-Native Vector Database with Built-In Hybrid Search

What Makes Weaviate Different

Three architectural decisions set Weaviate apart from other vector databases. First, native hybrid search. Weaviate maintains both an HNSW vector index and a BM25 inverted index on every collection. You can query using pure vector similarity, pure keyword matching, or a weighted blend of both. The alpha parameter controls the mix: alpha = 1.0 is pure vector, alpha = 0.0 is pure keyword, and values in between merge scores from both indexes using reciprocal rank fusion. This eliminates the need to run a separate Elasticsearch or Typesense instance alongside your vector database.

Second, built-in vectorization. Weaviate's vectorizer modules connect to embedding providers, OpenAI, Cohere, Hugging Face, Google, or local models, and generate embeddings automatically when you insert data. You send plain text, Weaviate sends it to the configured embedding model, stores both the text and the resulting vector, and handles all the embedding API calls transparently. This simplifies your application code because you do not need to manage an embedding pipeline separately.

Third, a GraphQL-based query API. While Weaviate also provides REST endpoints for CRUD operations, its primary query interface is GraphQL. This gives you structured, composable queries with explicit field selection, nested objects, and aggregation operations. The learning curve is steeper than a simple REST API, but the expressiveness pays off for complex query patterns.

Schema and Data Model

Weaviate organizes data into classes (renamed to "collections" in newer documentation, but the concept is the same). Each class defines a set of properties with data types, a vectorizer module, and an index configuration. You define your schema before inserting data, though Weaviate can auto-generate schemas if you enable auto-schema mode.

Supported property types include text, int, number, boolean, date, uuid, geoCoordinates, phoneNumber, blob, object, and cross-references (links between objects in different classes). Cross-references are a unique Weaviate feature that lets you model relationships between objects, similar to foreign keys in relational databases but across vector-indexed collections.

A practical schema for an AI agent's knowledge base might define a Document class with properties for title (text), content (text), source_url (text), category (text), created_at (date), and word_count (int). The class configuration specifies the vectorizer (text2vec-openai, for example), the vector index type (hnsw), and the distance metric (cosine). Weaviate automatically vectorizes the text properties and indexes the result.

Multi-tenancy is supported natively. You can enable multi-tenancy on a class, which creates isolated data partitions for each tenant. Tenants share the schema definition but have completely separate data stores. This is more efficient than metadata filtering for tenant isolation because there is no filter evaluation overhead, each tenant's data is physically separated.

Hybrid Search in Practice

Hybrid search is Weaviate's strongest differentiator, and it solves a real problem that pure vector databases struggle with. Consider an AI customer support agent. A customer types "error code ERR-5012 when uploading files over 25MB." A pure vector search might find documents about file upload errors in general, but it could miss the specific document about ERR-5012 because that exact code is just one string among millions of embedded tokens. A pure keyword search would find the ERR-5012 document but miss related articles about upload limits that use different terminology.

Weaviate's hybrid search runs both searches simultaneously and merges the results. The BM25 component finds the exact ERR-5012 match. The vector component finds semantically related documents about file upload issues, size limits, and error handling. The merged result set gives the agent both the specific answer and broader context, which is exactly what a good support response needs.

Configuring the alpha parameter requires understanding your query patterns. For knowledge bases where users frequently search with specific identifiers (product codes, error codes, ticket numbers), set alpha to 0.3 to 0.5, weighting keyword matching more heavily. For conversational AI agents where queries are natural language questions, set alpha to 0.7 to 0.9, weighting semantic similarity more heavily. You can also adjust alpha per query, not just per collection, allowing your application to choose the right balance dynamically based on the query type.

The fusion algorithm combines scores from both search methods using ranked fusion or relative score fusion. Ranked fusion assigns points based on result position (first result gets the most points, last gets the fewest) and sums across both result sets. Relative score fusion normalizes the actual similarity scores from both methods to a 0-1 range and computes a weighted average. Relative score fusion generally produces better results because it preserves the magnitude of match quality, not just the ranking.

Vectorizer Modules

Weaviate's module system supports multiple embedding providers simultaneously. Each class can use a different vectorizer, and you can change vectorizers by creating a new class with a different configuration and migrating data.

text2vec-openai: Uses OpenAI's embedding models. Supports text-embedding-3-small, text-embedding-3-large, and ada-002. Requires an OpenAI API key set as an environment variable or passed per request.

text2vec-cohere: Uses Cohere's embedding models including embed-v4. Supports input type specification (search_document for inserts, search_query for queries) which can improve retrieval quality.

text2vec-huggingface: Connects to Hugging Face's Inference API or a locally hosted model. Useful for open-source embedding models like BGE, Nomic Embed, or E5.

text2vec-transformers: Runs a Sentence Transformers model locally inside a Docker container alongside Weaviate. This eliminates external API calls entirely, keeping all data processing local. The trade-off is increased resource consumption, the model container needs its own GPU or substantial CPU allocation.

multi2vec-clip: Uses CLIP models for multimodal embeddings, allowing you to store and search across both text and images in the same vector space. An image of a cat and the text "a photo of a cat" would be nearby in the embedding space.

The vectorizer handles both insert-time and query-time embedding. When you insert an object with text properties, Weaviate sends the text to the configured model and stores the resulting vector. When you query, Weaviate embeds the query text using the same model before searching. This ensures embedding consistency without your application managing the embedding pipeline.

Deployment and Infrastructure

Docker Compose is the standard self-hosted deployment. The official docker-compose.yml includes the Weaviate server and any vectorizer module containers you need. A minimal setup with text2vec-openai requires only the Weaviate container (the OpenAI API is called over the network). A self-contained setup with text2vec-transformers requires an additional container running the embedding model.

Resource requirements are higher than Qdrant due to Weaviate's Go runtime and the additional index structures for hybrid search. For 1 million vectors at 1536 dimensions, plan for 8GB of RAM minimum (compared to 4GB for Qdrant). For 5 million vectors, plan for 32 to 48GB. The BM25 inverted index adds roughly 30 to 50% to the memory footprint compared to a pure vector index.

Kubernetes deployment uses Weaviate's official Helm chart. The chart supports multi-node clusters with configurable replication factors, shard counts, and resource limits per pod. Weaviate's clustering uses a Raft-based consensus protocol for schema management and consistent hashing for data distribution.

Weaviate Cloud provides a fully managed service on AWS. The free sandbox tier includes a single-node instance with limited resources, suitable for development and testing. Production tiers start at approximately $25 per month for a small instance and scale based on node count, storage, and compute. The API is identical between self-hosted and cloud deployments.

Performance Characteristics

Weaviate's query performance is competitive with Pinecone and moderately slower than Qdrant due to its Go runtime and the overhead of maintaining dual indexes.

Vector-only query latency at 1 million vectors: 4.5ms median, 11ms p99. This is fast enough for interactive AI agent workloads. Under 100 concurrent queries, p99 rises to 20 to 25ms.

Hybrid query latency at 1 million vectors: 8 to 15ms median, depending on the alpha parameter and result count. Hybrid queries are inherently slower than pure vector queries because two indexes are traversed and results are merged.

Write throughput: 4,000 to 10,000 objects per second with pre-computed vectors, 200 to 500 objects per second when using a vectorizer module (bottlenecked by embedding API latency). Batch imports are significantly faster than individual inserts.

Memory per million vectors (1536d): Approximately 10 to 14GB with HNSW index and BM25 inverted index. This is roughly 40% more than Qdrant's 7 to 9GB for the same dataset because of the dual index structure.

Strengths

Best hybrid search implementation. The ability to blend semantic and keyword search in a single query is genuinely useful for applications where users alternate between natural language questions and specific term searches. No other vector database does this as cleanly.

Built-in vectorization simplifies architecture. Eliminating the separate embedding pipeline reduces code complexity and potential failure points. The vectorizer module handles retries, batching, and error recovery for embedding API calls.

Cross-references model relationships. The ability to link objects across collections mimics relational database foreign keys, enabling graph-like queries that other vector databases cannot express. An agent can traverse from a customer to their tickets to the knowledge base articles referenced in those tickets.

Mature multi-tenancy. Native tenant isolation is more efficient than metadata filtering for SaaS applications serving hundreds or thousands of tenants. Each tenant gets physically separated storage with independent lifecycle management.

Limitations

Higher resource consumption. Dual indexes mean more RAM, more disk, and more CPU compared to pure vector databases. Budget 40 to 50% more infrastructure cost than Qdrant for equivalent datasets.

Steeper learning curve. GraphQL queries, schema definitions, module configuration, and the class-based data model require more upfront learning than Pinecone's simple REST API or ChromaDB's four-line setup. Documentation is extensive but can be overwhelming for beginners.

Go runtime limitations. While Go is generally performant, its garbage collector introduces occasional latency spikes under heavy load. The p99 latency gap between Weaviate and Qdrant widens under concurrent query pressure, from 3x at low concurrency to 5x at high concurrency.

Vectorizer dependency. If you rely on built-in vectorization with an external API (OpenAI, Cohere), your database's insert performance depends on that API's availability and latency. An OpenAI API outage means Weaviate cannot embed new data, though existing vectors remain searchable.

When to Choose Weaviate

Choose Weaviate when your application genuinely needs hybrid search, combining semantic similarity with keyword matching. Choose it when you want to simplify your architecture by letting the database handle embedding generation. Choose it when you need cross-reference relationships between objects. Choose it when you are building a multi-tenant SaaS product with per-tenant data isolation.

Do not choose Weaviate if your primary concern is minimizing latency (choose Qdrant), minimizing operational complexity (choose Pinecone), or minimizing infrastructure cost (choose pgvector or self-hosted Qdrant). Weaviate's strengths are features, not efficiency.