What is endee-io/endee?

Endee is an AGPL-3.0 C++ search engine for RAG, semantic and hybrid retrieval, shipped as a local build script or a Docker image. The README documents the API surface and the operational extras, but not the query syntax or the rollback story.

Can I use endee-io/endee commercially?

Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.

Is endee-io/endee still maintained?

Yes. The repository last received commits 48 days ago.

What programming language is endee-io/endee written in?

Mainly C++, according to GitHub's language statistics.

Endee vector database review: install, API, limits

At a glance

What is it?: Endee is an AGPL-3.0 C++ search engine for RAG, semantic and hybrid retrieval, shipped as a local build script or a Docker image. The README documents the API surface and the operational extras, but not the query syntax or the rollback story.
Who is it for?: Endee fits teams that want a self-hosted retrieval layer with payload filtering and sparse vectors, are comfortable building C++ with AVX2 or NEON flags, and can accept AGPL-3.0 obligations. It is the wrong choice if you need a managed service with an SLA, or if you cannot run the install script on a supported CPU.
Can I use it commercially?: Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
Is it still maintained?: Yes. The repository last received commits 48 days ago.
What is it written in?: Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 15, 2026 · endee-io/endee

What Endee is for, and who it is aimed at

Endee is a vector search engine written in C++, positioned in the README as an "AI Search & Intelligence platform" for RAG pipelines, semantic search, hybrid search, recommendation systems and filtered vector retrieval APIs. The repository description makes a scale claim: up to 1B vectors on a single node, with performance coming from indexing and execution work rather than from sharding across machines. That claim is the project's own and the README does not reproduce a benchmark methodology for it, so treat it as a design target, not a measured number.

The intended user is a team that wants to run retrieval itself. The feature list is about control: payload filtering, sparse vectors for hybrid retrieval, backup APIs, logging and instrumentation, and CPU-targeted builds. If your retrieval layer is a black box you call over HTTPS and you never want to think about AVX512, this project is aimed at someone else. If you want to own the process, pick the CPU flags and keep the index on your own disk, the repository is organised around that workflow.

The mechanism: C++ server, HTTP API, CPU-targeted build

The architecture visible in the repository is a single server binary plus a data directory. CMakeLists.txt and src/ hold the C++ implementation, tests/ holds the test tree, third_party/ holds vendored dependencies, and docker-compose.yml runs the image as a service named endee-oss. The README states the server listens on port 8080, and the compose file maps "8080:8080" and mounts a named volume at /data, so index state lives outside the container.

Two environment variables appear in the compose file. NDD_NUM_THREADS is set to 0, which the file presents as the default without explaining the semantics, and NDD_AUTH_TOKEN is an empty string with the comment "Replace with your auth token". The README points to docs/getting-started.md for authentication examples rather than inlining them, so the token format and the endpoints that require it are not visible in the README itself.

The CPU story is the other half of the mechanism. The README says the project is "optimized for modern CPU targets, including AVX2, AVX512, NEON, and SVE2", and the install example passes --avx2 explicitly. That means the build you produce is tied to a CPU feature set. It also means the Docker image you pull was built for some target, and the compose file does not say which. That is a real gap: a container built for AVX512 will not run correctly on a host without it, and nothing in docker-compose.yml lets you select the target.

Installing Endee locally and running the server

The README's fastest local path is two scripts at the repository root. The first makes them executable and runs the installer with the release and AVX2 flags, the second starts the server.

bash

chmod +x ./install.sh ./run.sh
./install.sh --release --avx2
./run.sh

After ./run.sh, the README states the server listens on port 8080. The README does not show a health-check endpoint or a startup log line to look for, so the first confirmation available from the README alone is that the process is running and the port is bound.

The Docker route is the alternative when you do not want to build. The compose file defines the service, the port mapping and the data volume:

yaml

services:
  endee-oss:
    image: endee-oss:latest
    container_name: endee-oss
    ports:
      - "8080:8080"
    environment:
      NDD_NUM_THREADS: 0
      NDD_AUTH_TOKEN: ""
    volumes:
      - endee-data:/data

The image name is endee-oss:latest, which is a locally tagged image, not a registry path. The README mentions "prebuilt registry images" as a deployment option but does not name a registry in the text available here, so a first-time user has to check docs/getting-started.md or the hosted docs at docs.endee.io/quick-start before docker compose up will find anything.

For a first real use, the README does not give a worked create-index-then-search example. It says Endee "exposes an HTTP API for managing indexes and serving retrieval workloads" and points at the getting-started guide for the current examples. The honest first step is therefore to read docs/getting-started.md and docs/filter.md, then call the index-creation endpoint described there. The README does not contain a request body to copy, so the getting-started guide is where that has to come from.

Hybrid search and payload filtering are documented separately

Two features carry most of the retrieval logic, and both live in their own documents rather than in the README. Sparse vector support is in docs/sparse.md, and payload filtering is in docs/filter.md. The README describes the combination as improving relevance "where both semantic understanding and term-level precision matter", which is the standard argument for hybrid retrieval: dense vectors handle paraphrase, sparse terms handle exact tokens like part numbers or error codes.

Filtering is the piece that decides whether a vector database is usable for application queries at all. A RAG system that retrieves semantically similar chunks but cannot restrict them to a tenant, a document type or a date range is not a production retrieval layer. Endee ships the feature and documents it, which is more than some engines do, but the README does not describe the filter expression syntax, the supported operators, or whether filtering happens before or after the approximate nearest-neighbour search. That last question matters a lot in practice: post-filtering can return fewer results than requested when the filter is selective. Anyone evaluating Endee for filtered retrieval should read docs/filter.md before assuming the behaviour.

Where Endee is the wrong tool

The most concrete limitation is the licence. Endee is AGPL-3.0. If you modify it and expose it to users over a network, the AGPL's network clause is the part your legal team will want to read. For a purely internal deployment the obligation is lighter, but this is a decision about your product, not about the software's quality.

The second limitation is the build matrix. The README presents AVX2, AVX512, NEON and SVE2 as supported targets, and the install example pins --avx2. Nothing in the repository describes a portable fallback build for CPUs without those extensions. If your fleet is mixed, or you deploy to a cloud instance whose CPU generation you do not control, you have to verify the target yourself.

The third is documentation depth. The README is a good index and a thin manual. It links to docs/sparse.md, docs/filter.md, docs/backup-system.md, docs/logs.md and docs/mdbx-instrumentation.md, and it points to hosted docs for the API. It does not document rollback, does not document a client library in the repository, and does not reproduce a benchmark for the 1B-vector figure. A team that needs a fully specified API reference before writing code will spend its first day in docs.endee.io rather than in the repository.

Finally, the release history is uneven. The recent tags are 1.3.0, v1.3.4 and 1.3.5, with the two most recent pushes to the default branch dated 2026-04-17 and 2026-05-22 and the last push to the repository on 2026-07-29. The README still links its "Release Notes" entry to the 1.0.0 tag, which is stale relative to the tags above it. Small thing, but it tells you the repository is maintained by a small group rather than a documentation team.

How it compares with Qdrant and pgvector

The closest comparison in shape is Qdrant: a standalone vector search service with its own HTTP and gRPC APIs, payload filtering, and a self-hosted or managed deployment. The difference in approach is packaging and licence. Qdrant is Apache-2.0 and ships official clients for several languages; Endee is AGPL-3.0 and the README says the current documentation and examples "focus on running the server directly and calling its API endpoints". If you need a permissively licensed engine to embed or resell, that single difference decides the evaluation before performance enters the conversation.

The other comparison is pgvector, which puts vector search inside PostgreSQL. The trade-off is the inverse of Endee's: you inherit SQL, transactions and your existing backup tooling, but you inherit the database's memory model and index build behaviour too. Endee's pitch is a purpose-built engine with CPU-specific optimisation and a documented backup API, at the cost of running and operating another service. Neither is strictly better; they fail in different ways. pgvector strains when the vector table grows past what the Postgres instance can hold in memory, while Endee asks you to trust a smaller project's operational story.

If your workload is hybrid retrieval with heavy metadata filtering at high query volume, and you can run your own infrastructure, Endee is worth a benchmark against Qdrant on your own data. If your workload is modest and already lives in Postgres, pgvector removes an entire service from your stack.

Licence, maintenance and upgrade cost

Endee is licensed AGPL-3.0, and the LICENSE file sits at the repository root. The practical consequence is that the network-copyleft clause applies to modified versions offered to users over a network. Running the unmodified server behind your own API is the common pattern, but the boundary between "using" and "conveying a modified version" is a legal question, not an engineering one, and the repository's SECURITY.md and CONTRIBUTING.md do not address it. Get your own advice.

On maintenance, the last push to the default branch was on 2026-07-29, and the most recent tagged release in the list is 1.3.5 from 2026-05-22. The repository is not archived. The upgrade path is not described in the README: there is no migration guide, no statement about index format compatibility between 1.3.x releases, and no documented rollback. The backup APIs in docs/backup-system.md are the mechanism the project gives you, and the sensible upgrade procedure is to take a backup, replace the binary or image, and restart against the same /data volume. Whether an older index opens under a newer binary is exactly the thing the README does not say, so test it on a copy of the volume before you touch production.

Editorial conclusion

Endee fits teams that want a self-hosted retrieval layer with payload filtering and sparse vectors, are comfortable building C++ with AVX2 or NEON flags, and can accept AGPL-3.0 obligations. It is the wrong choice if you need a managed service with an SLA, or if you cannot run the install script on a supported CPU. Before committing, verify three things the README leaves open: the exact index-creation and search request bodies, whether the release you need was built for your CPU target, and how a restore from the backup APIs behaves on a fresh volume.

Frequently asked questions

What is the Endee vector database?

Endee is a C++ vector search engine for AI retrieval, semantic search and hybrid search, distributed as an AGPL-3.0 repository with a local install script and a Docker Compose file. The README describes it as an AI Search & Intelligence platform for RAG pipelines, recommendations and filtered vector retrieval APIs.

How do I install and run Endee locally?

The README's fastest path is to make the two root scripts executable, run ./install.sh --release --avx2, then ./run.sh. The server then listens on port 8080, and the README points to docs/getting-started.md for the full build, Docker and authentication instructions.

Which port does the Endee server use, and how is data persisted in Docker?

The README states the server listens on port 8080, and docker-compose.yml maps "8080:8080" for the endee-oss service. The same file mounts a named volume, endee-data, at /data, so index state survives container restarts.

Does Endee support hybrid search and metadata filtering?

Yes. The README lists hybrid retrieval with sparse vectors and payload filtering as features, with separate documentation in docs/sparse.md and docs/filter.md. The README does not describe the filter expression syntax or the supported operators, so those documents are the place to look.

Official sources

Community notes