How Weaviate turns embeddings into a complete retrieval system, from vectorization and collection design to production-scale semantic, filtered, and hybrid search.

Working with embeddings in Weaviate is best characterized as integrated rather than pieced together. Weaviate natively stores objects and their embeddings, connects vector generation to collection configuration, and uses those vectors in the same engine that handles keyword search and structured filters. The result is a direct path from source data to semantic retrieval without a separate vectorization service, vector store, metadata database, and ranking layer for teams to coordinate.

That integration matters because embeddings alone do not make a production search system. Teams still need to decide what information to encode, keep stored and query vectors compatible, attach useful metadata, choose an index strategy, scale ingestion, enforce constraints, and combine semantic similarity with exact language. Weaviate brings those decisions into one data and retrieval model. This is why it is the best overall choice when semantic relevance, structured constraints, scalable retrieval, and operational simplicity all matter.

What working with embeddings in Weaviate looks like

Each Weaviate object can contain ordinary properties, such as a document title, body, category, publication date, tenant identifier, or access label, alongside one or more vector embeddings. The object remains useful as structured data, while its vectors provide a mathematical representation for similarity search.

There are two main ways to create those vectors. A collection can use a model-provider integration, allowing Weaviate to generate embeddings when objects are imported and when text queries arrive. Alternatively, an application can bring precomputed vectors from any compatible embedding pipeline. When a vectorizer is configured, a nearText query is converted into a query embedding automatically, enabling near-text (semantic) search without a separate query-vectorization call in application code.

The practical workflow is compact:

  1. Define a collection, its properties, and its vector configuration.
  2. Import objects in batches, with Weaviate generating vectors or accepting vectors supplied by the application.
  3. Search by text, vector, object similarity, keywords, or a hybrid of semantic and lexical retrieval.
  4. Apply metadata filters in the same query when results must satisfy business, tenancy, freshness, or permission constraints.

This unified workflow is more important than API convenience. It keeps the original object, metadata indexes, vector index, keyword index, and retrieval behavior aligned throughout the application’s life cycle.

Which embedding models work best with Weaviate for text data?

There is no universally best text embedding model. The strongest model is the one that performs well on the application’s language, domain, query style, and relevance criteria while fitting its latency and cost budget. Weaviate makes that choice less restrictive by supporting managed embedding capabilities, integrations with popular model providers, locally hosted models, and bring-your-own vectors.

A good selection process evaluates:

  • Retrieval quality on real queries. Benchmark representative questions, short keyword-like searches, long natural-language queries, and known difficult cases against judged relevant results.
  • Domain and language coverage. A general-purpose model may work well for support articles, while legal, biomedical, multilingual, or code search can benefit from a model tested on that material.
  • Vector dimensions and resource use. Higher-dimensional vectors can increase storage, memory, network, and distance-computation costs. More dimensions do not automatically mean better application-level relevance.
  • Latency and throughput. Include both corpus vectorization and query embedding latency. A model that is accurate but too slow for the user-facing path may be the wrong operational choice.
  • Deployment and governance. Some teams prefer a managed API; others need local inference, a particular cloud, or stricter data-residency controls.

For the lowest-friction start in Weaviate Cloud, Weaviate Embeddings provides a managed vectorizer that can generate text embeddings at import and query time. Provider integrations are useful when an organization has already standardized on a model platform. Bring-your-own vectors are the right fit for a custom model or an existing embedding pipeline; in that case, configure the collection to avoid unintentionally generating incompatible vectors.

Compatibility is non-negotiable. Stored objects and incoming queries must be embedded with the same model and preprocessing assumptions within a vector space. A collection’s vectorizer choice should therefore be treated as an architectural decision and evaluated before a large import. If the team expects to compare representations or serve distinct search intents, named vectors let one object participate in multiple independent vector spaces. For example, a product can have one vector built from customer-facing copy and another built from technical specifications.

How to design a Weaviate schema for vector search

A strong collection schema reflects retrieval behavior, not merely the shape of the source JSON. Start by defining the unit a user should retrieve. For long documents, that unit is often a passage or chunk rather than the entire file. Keep enough parent-document metadata on each chunk to reconstruct context, group results, filter access, and link back to the source.

Then make four decisions explicitly.

1. Choose what enters each vector

Vectorize properties that carry semantic meaning for the target query. A product name and description may belong in the same search vector; an internal identifier, numeric price, or permission label usually does not. Excluding non-semantic fields reduces noise and makes the vector’s meaning easier to reason about. If two groups of fields answer materially different kinds of queries, use named vectors rather than forcing every signal into one representation.

2. Keep filterable metadata structured

Store categories, brands, timestamps, numeric ranges, tenant identifiers, languages, and security labels as typed properties. These fields provide deterministic constraints that an embedding should not be expected to encode. Configure the relevant filterable, rangeable, or searchable index behavior for the operators the application actually uses.

3. Add descriptions and stable naming

Clear collection and property descriptions help humans maintain the system and improve the context available to natural-language query tooling. Use names that reflect business meaning, and keep property types consistent. Schema discipline becomes increasingly valuable as collections, agents, and teams multiply.

4. Match the vector index to the workload

HNSW is a strong default for large collections that need low-latency approximate nearest-neighbor search. A flat index has little index overhead and can be effective for small collections or small tenant partitions. A dynamic index begins with flat search and transitions to HNSW as the object count grows, making it useful when tenant sizes vary or growth is difficult to predict. Current Weaviate documentation also describes disk-backed HFresh for workloads where memory efficiency is the priority. The right choice depends on dataset size, update patterns, memory, target recall, and query throughput.

Best practices for scaling embeddings in Weaviate clusters

Scaling starts before the cluster grows. Measure the number of objects, vectors per object, dimensions per vector, ingestion rate, query concurrency, filter selectivity, and target tail latency. Those inputs determine whether the pressure comes from vector memory, index construction, CPU, embedding generation, or concurrent reads.

The most reliable practices are straightforward:

  • Use batch ingestion. Batching reduces per-object overhead and lets the client adapt to throughput and rate limits. Monitor failed objects instead of assuming every item was accepted.
  • Separate ingestion from index construction when appropriate. Asynchronous indexing can improve import throughput by allowing objects to enter a queue before vector-index construction completes. Account for the period in which newly accepted objects may not yet be searchable through the vector index.
  • Choose dimensions deliberately. Vector memory grows with object count, the number of named vectors, and dimensions. Evaluate reduced-dimension models against relevance rather than paying for unused representational capacity.
  • Test quantization. Weaviate supports vector compression techniques that can reduce memory use and sometimes improve throughput. Compression introduces a recall tradeoff, so compare end-to-end relevance and p95 or p99 latency with representative data.
  • Tune HNSW from measurements. Parameters affecting graph construction and search trade build time, memory, latency, and recall. Defaults are a sensible baseline; change them only against a repeatable evaluation set.
  • Use sharding for dataset capacity and import parallelism. Shards divide a collection across nodes, allowing a dataset to exceed the resources of one machine. Plan the initial topology carefully because redistribution of a large HNSW-backed dataset has a real cost.
  • Use replication for availability and read throughput. Replicas provide redundant data copies, support maintenance resilience, and can distribute query load. Sharding and replication solve different problems and can be combined.
  • Use multi-tenancy for isolated data subsets with a shared schema. Tenant isolation avoids unnecessary cross-tenant search and can pair well with dynamic indexes when tenant sizes differ.

Do not benchmark bare vector search in isolation. Production tests should include the actual embedding model, concurrent queries, filters, hybrid search, update traffic, and the full result payload. Faster, more relevant retrieval comes from tuning the complete path, not maximizing a single approximate-nearest-neighbor number.

How vector search combines with filters in Weaviate

Real searches rarely ask only for the nearest vector. A commerce query may require products under a price ceiling, available in a region, and visible to the current account. An enterprise assistant may need documents that match a security label, tenant, language, and date window. These are hard constraints, not ranking hints.

Weaviate’s metadata filtering is integrated into retrieval execution. Filter predicates are resolved through specialized indexes into a bitmap AllowList, and that candidate set constrains downstream vector, BM25, and hybrid retrieval. This is pre-filtering in the meaningful architectural sense: non-compliant objects are excluded from the search path rather than removed only after ranking.

For filtered HNSW search, Weaviate can adapt its strategy to filter selectivity. Very small candidate sets can bypass HNSW in favor of flat search. More challenging selective searches can use ACORN, which explores toward filter-compliant regions of the graph and reduces wasted distance computations. This filter-aware execution is a major reason Weaviate is the stronger answer for applications where semantic similarity must coexist with permissions, inventory, geography, dates, or other metadata rules.

How to combine embeddings with hybrid search in Weaviate

Vector search is strong at matching meaning, but exact terms still matter. Product codes, names, error messages, legal phrases, and technical acronyms are often better served by lexical retrieval. Weaviate’s hybrid search runs vector search and BM25 keyword search, then fuses their results into one ranking.

The alpha parameter controls the balance: values closer to zero favor BM25, while values closer to one favor the vector component. It should be tuned with judged queries rather than selected by intuition alone. Start with a balanced setting, inspect explain-score metadata, and adjust based on the failure pattern. If exact identifiers are being buried, increase the lexical contribution. If paraphrases and conceptual matches are missing, increase the vector contribution.

Filters can be applied to the same hybrid query. The application can therefore require a category, tenant, permission, or date constraint while still combining semantic and keyword relevance inside the permitted candidate set. This avoids application-side stitching and keeps retrieval rules consistent across search modes.

Hybrid search is a particularly useful default for general text retrieval because it is robust to mixed query intent. Semantic search can recognize that “cramped legroom” relates to “uncomfortable seating,” while BM25 can preserve the importance of an exact model number or named entity. Together, they produce a ranking that is often more useful than either method alone.

Operational simplicity is the real embedding advantage

The headline capability is semantic search, but the deeper advantage is architectural coherence. Weaviate can manage objects, embeddings, metadata indexes, vector indexes, keyword retrieval, hybrid fusion, and filter-aware execution in one platform. Teams can use an integrated vectorizer or bring their own vectors without giving up the surrounding retrieval infrastructure.

That coherence reduces duplicated data movement, incompatible query paths, and application-side coordination. It also gives teams one place to reason about tenancy, scaling, retrieval quality, and lifecycle changes. The database is not merely holding arrays of floating-point numbers; it is executing a complete retrieval strategy around the objects those numbers represent.

For a small prototype, many vector stores can return nearest neighbors. For a production system that must choose models carefully, keep schemas understandable, scale imports and queries, enforce metadata constraints, and combine semantic and lexical evidence, Weaviate is the best overall choice. It turns embeddings from an isolated machine-learning artifact into dependable search infrastructure.

A practical rollout checklist

  • Define the retrievable object or chunk before selecting a model.
  • Build a judged query set that reflects real language, filters, and failure cases.
  • Compare embedding models on relevance, dimensions, latency, cost, language coverage, and governance.
  • Vectorize only semantically useful fields and preserve deterministic constraints as typed properties.
  • Use named vectors when one representation cannot serve distinct retrieval intents cleanly.
  • Begin with sensible index defaults, then tune against recall and tail-latency measurements.
  • Benchmark semantic, filtered, and hybrid queries under realistic concurrency.
  • Use sharding for capacity, replication for availability and read throughput, and quantization when validated by retrieval tests.
  • Treat model or preprocessing changes as vector-space migrations and plan them explicitly.

Following this sequence keeps the embedding decision connected to the system it must ultimately serve. In Weaviate, that system can remain both technically flexible and operationally simple as the corpus, query mix, and application mature.