In Weaviate, what does setting a text2vec vectorizer on a collection do?

## The idea Most vector stores are strictly a place to put vectors: you run an embedding model yourself, and you hand the store a list of floats. Weaviate can do that too, but it also offers *modules* — server-side plugins that call an embedding model on your behalf. A `text2vec-*` module turns text into a vector; `multi2vec-clip` turns images and text into one shared space. Attaching one to a collection means Weaviate, not your application, is responsible for producing embeddings for that collection. ## Configuring it In the v4 Python client the module is part of the collection definition: Collection creation takes `vectorizer_config=Configure.Vectorizer.text2vec_openai()` (older spelling) or, on recent clients, `vector_config=Configure.Vectors.text2vec_openai()`. Either way the choice is baked into the collection at creation time. It is schema, not a per-request option — you cannot flip a collection from one vectorizer to another and have existing objects re-embed themselves. ## What happens on import When you call `data.insert({"title": "...", "body": "..."})`, the server: 1. Assembles a single text string from the object's vectorizable properties. 2. Sends that string to the configured model (an HTTP call to the provider for `text2vec-openai`, or to a local inference container for `text2vec-transformers`). 3. Stores the returned vector alongside the object and inserts it into the collection's ANN index. So import throughput is bounded by the embedding backend, not by Weaviate. A large batch import is effectively a large batch of model calls. If the provider rate-limits or errors, those objects fail to import; in the v4 batch API the offending objects show up in the batch's `failed_objects`, which is the first place to look when a load run "succeeded" but the collection is short of rows. ## What happens on query A vector search needs a query vector. With a vectorizer configured, a text query is embedded by the *same* module before the nearest-neighbour lookup runs, so query and corpus land in the same space automatically. That convenience has a cost: every text query pays one extra network round-trip to the embedding provider before Weaviate does any of its own work. Under load this is often the dominant term in p99 latency, and it is a dependency your database now has on a third party. Searching with a vector you already have avoids the round-trip entirely. ## Credentials and enablement Two things must be true for a hosted module to work. First, the module has to be enabled on the server process — the `ENABLE_MODULES` environment variable lists the modules the instance loads, and `DEFAULT_VECTORIZER_MODULE` can set the fallback for collections that do not name one. A schema referencing a module the server did not load is rejected. Second, the module needs a credential. Weaviate deliberately does not persist API keys in the schema; you pass them per connection as headers, for example `headers={"X-OpenAI-Api-Key": ...}` on `connect_to_local`. A common first failure is a working schema plus a client that forgot the header, which surfaces as an error on the first insert rather than at create time. ## What it does not change The vectorizer decides how vectors are *produced*. It does not decide how they are *indexed* — HNSW versus flat, and the index's own parameters, are separate configuration. It also does not change the shape of your data model: properties, types and filters are unaffected. ## When it is the wrong choice Server-side vectorization is a good fit when the collection's text is the thing you search and you would otherwise write a small embedding service of your own. It fits badly when you need one model version pinned across several systems, when you want to embed on your own GPU fleet with your own batching, when the same text is already embedded elsewhere in your pipeline and re-embedding it is wasted spend, or when you cannot accept a synchronous external dependency in the query path. In those cases you configure no vectorizer and supply vectors yourself.