weaviate/recipes: What the Notebook Collection Actually Contains

The Gap Between Weaviate's API Reference and a Working Pipeline

Weaviate's own documentation explains individual operators: nearText, hybrid, nearImage, nearVideo, .generate, filters, reranking. What it does not do, at least not in one place, is show those operators wired into a full pipeline with a real dataset, a real model provider and a real output. That gap is what this repository fills. The README describes it as covering "end-to-end examples of the various features and integrations with Weaviate", and the four top-level directories map onto that promise: datasets, integrations, weaviate-features and query-agent. The audience is an engineer who has already decided to try Weaviate and now needs to see a query return something before committing further. It is not aimed at someone choosing a vector database from scratch, and it is not a reference implementation you would ship. The notebooks are working examples, and the value is in the middle of the file, not the header.

Four Directories, Four Different Kinds of Example

The repository is organised by intent rather than by technology. Datasets holds ready-to-ingest data for a Weaviate cluster, which matters because most vector search tutorials stall at the point where you need something to embed. Integrations holds notebooks pairing Weaviate with another product. Weaviate Features holds notebooks on the database's own capabilities. Query Agent holds notebooks for Weaviate's agent layer. The README splits Query Agent into three modes, and the distinction is concrete: Ask turns a query into searches or aggregations and then answers the question, Search turns a query into searches and returns the matching objects directly, and Suggest Queries proposes queries based on what is in the collection. Those three modes fail differently. Ask can produce a fluent answer that misreads the retrieved objects, while Search hands you the objects and no interpretation. Knowing which mode a notebook uses tells you what to check when the output looks wrong.

The Integration Surface Is the Real Content

The integrations table is where this repository earns its place. It lists cloud hyperscalers (Google, AWS, NVIDIA), compute infrastructure (Modal, Replicate), LLM and agent frameworks (Agno, CrewAI, Composio, DSPy, Dynamiq, LangChain, LlamaIndex, Pydantic, Semantic Kernel, Ollama, Haystack, Modaic), data platforms (Databricks, Confluent, Box, Boomi, Spark, Unstructured, Firecrawl, Context Data, Aryn, Astronomer, Airbyte, IBM via Docling, Cardinal, Contextual AI, Chonkie, Parallel) and operations tooling (AIMon, Arize, Cleanlab, Comet, DeepEval, Langtrace, LangWatch, Nomic, Patronus AI, Ragas, TruLens, Weights & Biases). That is a broad list, and breadth has a cost. A notebook per integration means each one is maintained by whoever contributed it, and the README says plainly that this is "an ongoing project, and updates will be made frequently". Frequent updates are a warning as much as a promise: an integration notebook can lag the framework it demonstrates. The operations category is the one worth noticing, because evaluation and tracing are usually the last thing added to a RAG demo and here they have their own shelf.

Feature Notebooks Cover the Operators You Will Actually Type

The features table names model providers, filters, reranking, media search, classification, multi-tenancy, multi-vector embeddings, product quantization and evaluation. Several of these are not cosmetic. Multi-tenancy stores tenants on separate shards, which is a data isolation decision rather than a query tuning one. Product quantization compresses vector embeddings to reduce memory footprint, and the README frames it that way, as a memory measure. Multi-vector embeddings use ColBERT-style representations, which changes what gets stored per object and therefore what your index costs. Reranking is broken out by model provider, which is the right granularity, because the reranker is a separate model call with its own latency and its own API key. Media search covers nearImage and nearVideo, operators that behave differently from text search in ways a notebook can show faster than a paragraph can explain. Classification covers KNN and zero-shot, two approaches with different data requirements.

Getting a Notebook Running

There is no package to install. You clone the repository and open a notebook. The README does not document environment variables, a requirements file or a setup script, so the only reliable source for dependencies is the import and install cells at the top of the notebook you pick. Expect to need a Weaviate instance, which means either a local deployment or a hosted cluster, plus credentials for whichever model provider that notebook uses. The one documented workflow beyond reading notebooks is the contributor path: the README points to a guide at .docs/README.md for converting recipes into docs-friendly markdown. That tells you the notebooks are the source of truth and the published documentation is generated from them, which is a useful thing to know when the docs and the notebook disagree. Check the notebook, not the rendered page.

No Releases, No Stated Licence, No Stability Contract

The repository metadata shows no releases, and the licence field is unknown. Both facts matter. Without releases there is no version to pin and no changelog to read, so a notebook that worked against one Weaviate version may not work against the next, and you will find out by running it. Without a stated licence you cannot assume the terms under which the notebook code can be reused. The README invites contributions and issues, which suggests an open development model, but that is not the same as a licence grant. If you intend to copy notebook code into a product, resolve the licence question first rather than inferring it from the project's public posture. I am not giving legal advice here; the point is that the repository does not answer the question for you, and the metadata is the only place to look.

Where This Is the Wrong Tool

If you need a client library, this is not it. Weaviate's own client packages are the thing you import in production; the notebooks show how to call them. If you need something with a support contract, a semantic version and a deprecation policy, a notebook collection has none of those. If your pipeline is already built and you are debugging a specific failure, a general example notebook will not reproduce your data shape, and the time spent adapting it may exceed the time spent reading the client reference. The comparison worth making is against a framework's own example gallery, such as the LlamaIndex or LangChain documentation sets. Those are organised around the framework and treat the vector store as one interchangeable component among several. This repository is organised around Weaviate and treats the framework as the integration. If Weaviate is the fixed part of your stack, that orientation is correct. If you are still comparing vector stores, a framework-centric gallery will let you swap the store without rewriting the notebook, and this one will not.

Maintenance Cost and What to Verify Before You Copy

Treat every notebook as a snapshot rather than a dependency. The maintenance cost falls on you the moment you copy code out of it, because nothing in the repository tracks upstream changes in the integrations it demonstrates. The README's own framing, that updates will be made frequently, describes the maintainers' intent, not a guarantee that any particular notebook tracks the current API of the framework it uses. Practically, that means three checks before you lift anything: confirm the Weaviate client version the notebook imports matches yours, confirm the model provider API surface it calls still exists, and confirm the licence position. The Query Agent notebooks deserve an extra look, because the Ask, Search and Suggest Queries modes have different failure modes and the notebook will only demonstrate the one it was written for. Verify the mode you intend to use, in the notebook, before you build around it.

Editorial conclusion

Adopt weaviate/recipes when you are evaluating a specific Weaviate feature or integration and want a runnable starting point rather than prose. Do not adopt it if you need a supported library, a versioned release, or a licence you can confirm from the repository metadata, since none of those are present. Before copying anything, open the notebook you intend to use and check its install cell against your own Weaviate version, because the repository carries no releases and the notebooks are pinned only by whatever they import at the top.

Official sources

1. Issues
2. README
3. weaviate/recipes on GitHub