elastic/elastic-labs: Elasticsearch notebooks, sample apps and what they actually run

What elastic-labs is for, and who should open it

elastic-labs is the repository behind Elastic's Search Labs articles and tutorials. It collects executable Python notebooks, sample applications and supporting resources for using Elasticsearch as a vector database, for hybrid and semantic search, and for retrieval augmented generation, summarization and question answering. The README frames the audience directly: people who want to test Elastic platform capabilities before committing to them, including the Elastic Learned Sparse Encoder and reciprocal rank fusion, and people wiring Elasticsearch into LLM applications through OpenAI, Hugging Face or LangChain.

The practical reader is an engineer who already has an Elasticsearch deployment or is about to stand one up, and who wants to see a query, an ingest pipeline or a retriever configuration that works end to end. The repository is organized by intent rather than by API surface: notebooks/search holds a numbered sequence from 00-quick-start through 09-semantic-text plus semantic reranking examples, notebooks/generative-ai holds chatbot and question-answering notebooks, notebooks/langchain holds vector store and self-query retriever examples, and notebooks/document-chunking covers ingest pipelines, LangChain splitters and token counting.

If you are looking for a maintained Python package with a versioned API, this is the wrong shape of project. There are no releases in the repository, and the unit of distribution is the notebook file itself.

How the notebooks and apps are laid out

The top level separates four kinds of content. example-apps contains three runnable applications: a chatbot RAG app, an internal knowledge search app and a relevance workbench. notebooks contains the executable Python notebooks. datasets and supporting-blog-content hold data and companion material for articles, and supporting-video-content does the same for videos. docker and k8s hold deployment assets, and telemetry holds something the README does not explain.

The notebooks are the core artifact and they are meant to run against a live cluster. The README points at Colab as an easy way to get a Python virtual environment in the browser, which tells you the intended execution model: open a notebook, point it at an Elasticsearch endpoint, run the cells in order. Several notebooks are explicitly tied to Kibana Playground, including the OpenAI and Anthropic Claude 3 examples, so the flow there is Playground configuration backed by a notebook that exercises the same client calls.

The integration notebooks are the most opinionated part. There is a Hugging Face model loading notebook, an OpenAI kNN RAG notebook, an Amazon Bedrock LangChain QA example, and a Cohere inference API example. Each one bakes in a specific vendor's client library and a specific way of producing embeddings or reranking scores. That is the value and the constraint: you get a complete working path, and you inherit the vendor choice.

Installing the test harness and running your first notebook

There is no install step for the notebooks themselves. The README gives no pip install for the repository and no packaging metadata at the top level, so the way to consume a notebook is to open it in Colab or a local Jupyter environment and run its cells. What the repository does provide install steps for is its own notebook testing harness, driven by the Makefile.

The install target creates a virtual environment and pulls in the development requirements, which include pre-commit, plus the elastic-nbtest package used to execute notebooks.

make install

Running that target runs install-pre-commit and install-nbtest. The first creates a .venv, installs requirements-dev.txt quietly and installs the pre-commit hooks. The second creates the same .venv and installs elastic-nbtest into it. After it completes you should have a .venv directory at the repository root.

To execute the notebooks that the project considers testable, use the test target, which depends on both the harness install and the notebook run.

make test

The notebooks target does not take a hardcoded list. It expands NOTEBOOKS from a shell script:

NOTEBOOKS = $(shell bin/find-notebooks-to-test.sh)

That means bin/find-notebooks-to-test.sh is the authority on which notebooks are integrated with the testing framework. If you want to know whether a given notebook is exercised, read that script rather than the directory tree. bin/nbtest then receives the resulting list.

For a first real use, start with notebooks/search/00-quick-start.ipynb. It is the entry point the naming implies, and the search sequence continues into keyword querying and filtering, hybrid search, ELSER, multilingual search, query rules, the synonyms API, inference, learning to rank and semantic text. Expect to supply your own Elasticsearch connection details, since the README does not document a default endpoint or credential set for the repository as a whole.

What the sample code does not promise

The README is explicit about support boundaries, and this is the single most important paragraph in it. Elastic's official support services apply to your Elasticsearch deployment if you have a subscription. The README then states that these services do not apply to the sample application code contained in this repository. Read that as written: the notebooks and apps are illustrative, and a broken cell in a LangChain example is not a support ticket.

The maintenance signal is mixed. The repository is not archived, and its last push was on 2026-09-09, so it is being touched. But there are no releases, which means no versioned artifact, no changelog and no compatibility matrix. Nothing in the repository tells you which Elasticsearch version a given notebook targets. The model-upgrades notebook, upgrading-index-to-use-elser.ipynb, exists precisely because index mappings and inference configurations change between versions, and that is a hint about how brittle the surrounding examples can be.

There is also a structural duplication problem. The README lists question-answering.ipynb under both Generative AI and LangChain, pointing at the same path. When a repository's own index double-lists a file, you should treat the README as a rough map and the filesystem as the truth.

Finally, the notebooks assume external services. OpenAI, Cohere, Hugging Face and Amazon Bedrock examples all require credentials and network access to those vendors. If your environment forbids outbound calls to model providers, the integration notebooks are not usable as written, and the ELSER and semantic text notebooks, which rely on Elastic's own inference stack, become the more relevant subset.

elastic-labs against the Elasticsearch Python client and LangChain

The obvious alternative for programmatic Elasticsearch work is the official Elasticsearch Python client, which is a versioned library with a documented API surface. The difference in approach is fundamental: the client gives you request and response objects and expects you to know what to send, while elastic-labs gives you complete scenarios, including the index mappings, the ingest pipeline and the query body, and expects you to read the notebook to extract them. If you already know the query DSL you want, the client is the shorter path. If you are trying to find out what a hybrid retriever with reciprocal rank fusion looks like in practice, the notebook is faster.

The second alternative is LangChain's own Elasticsearch vector store integration. Several notebooks here, including langchain-vector-store.ipynb and langchain-vector-store-using-elser.ipynb, are thin demonstrations of exactly that integration. So the relationship is not competitive: elastic-labs is a set of worked examples for the client and for LangChain, not a replacement for either. The trade-off is that when LangChain changes its interface, the notebooks here can lag, and nothing in the repository declares a pinned LangChain version at the top level.

For pure keyword search, neither of these is the right comparison. The numbered search notebooks cover BM25 querying and filtering, so a team that only needs classic relevance tuning can use those directly and skip the vector material entirely.

Licence, upgrade cost and where to ask questions

The repository is licensed under the Apache License, version 2, and the LICENSE file sits at the top level alongside a NOTICE file. Apache-2.0 permits commercial use and modification with the usual conditions around notices and attribution, but this is a description of the licence text, not legal advice, and the sample apps may pull in third-party dependencies under their own terms.

The upgrade cost is the interesting part. Because there are no releases, there is no upgrade path in the conventional sense: you re-read the notebook. Elasticsearch itself changes query and inference APIs across minor versions, and the repository carries a dedicated model-upgrades notebook for moving an index to ELSER. If you copy a mapping or an inference pipeline out of a notebook into your own codebase, you own its forward compatibility from that moment. Nothing in the repository will tell you when the underlying API moves.

Support runs through channels rather than an issue tracker promise. The README points to the Elastic discuss forums and asks you to tag posts with #esre-elasticsearch-relevance-engine, and to the #search-esre-relevance-engine channel in the Elastic Community Slack. Both are community venues. The README also notes that the Search team at Elastic maintains the repository and is happy to help, which is a statement of intent rather than a service level.

Editorial conclusion

Adopt elastic-labs if you need a working reference for Elasticsearch vector search, hybrid retrieval or a RAG pipeline, and you are willing to read the notebook source rather than follow a manual. Do not adopt it as a library or as production code: the README states that Elastic subscription support services do not apply to the sample application code in the repository, and there are no tagged releases. Before you build on any notebook, verify the Elasticsearch version it targets and whether that notebook appears in the list produced by bin/find-notebooks-to-test.sh, because that list, not the directory listing, defines what the Makefile actually exercises.

Frequently asked questions

Official sources

1. elastic/elastic-labs on GitHub
2. Issues
3. License: Apache-2.0
4. README