Epsilla: a C++ vector database that indexes with graph traversal

The database shape is the selling point

Epsilla is described as an open-source vector database focused on scalability, high performance and cost-effectiveness of vector search, and the design decision that makes it approachable is that it is a database with familiar concepts rather than a vector store with an index API. The feature list says it plainly, a full fledged database management system with familiar database, table and field concepts where a vector is just another field type. So you create a database, create a table with fields, and one of those fields has a data type of vector with dimensions and a metric. Alongside that there is metadata filtering, hybrid search with a fusion of dense and sparse vectors, and built-in embedding support with natural language in and natural language out. The positioning in the readme is also stated, that EpsillaDB bridges the gap between information retrieval and memory retention in large language models. The primary language of the repository is C++, the licence is Apache-2.0, and the last push was on 2026-10-04.

Two steps to a running database

The quick start is a container and a client library. The image is pulled and run with a data volume mounted and the port published:

docker pull epsilla/vectordb
docker run --pull=always -d -p 8888:8888 -v /data:/data epsilla/vectordb

The Python client is installed separately:

pip install pyepsilla

So the architecture is a server process with a REST interface and a thin client that talks to it, which is the arrangement that lets the same database be shared and the same schema be reached from Python, JavaScript or Ruby. The port 8888 is the one the quick start uses, and the data directory is mounted at /data in the container, which is where the database files live. The image is pulled with --pull=always in the example, which is a hint about how frequently the image changes.

The client API, and what a table definition looks like

The Python client creates a database, selects it, defines a table and inserts records, and the table definition is where the vector field appears. Here the table has an integer primary key and a string field, and the index is declared against the string field:

from pyepsilla import vectordb

client = vectordb.Client(host='localhost', port='8888')
client.load_db(db_name="MyDB", db_path="/data/epsilla")
client.use_db(db_name="MyDB")

client.create_table(
    table_name="MyTable",
    table_fields=[
        {"name": "ID", "dataType": "INT", "primaryKey": True},
        {"name": "Doc", "dataType": "STRING"},
    ],
    indices=[
      {"name": "Index", "field": "Doc"},
    ]
)

Note the shape of the call. create_table takes a list of field definitions, each a name, a data type and optionally a primary key flag, and a separate list of indices, each naming a field to index. The data type is a string, and the naming follows the SQL style rather than a Python one, with the camel case field names carried through to the payload. The database path passed to load_db is the directory the container mounts, which is how the client finds the data the server owns.

Insert, then query, and the shape of the result

Records are inserted as a list of dictionaries keyed by field name, and the query takes a text query and a limit:

client.insert(
    table_name="MyTable",
    records=[
        {"ID": 1, "Doc": "Jupiter is the largest planet in our solar system."},
        {"ID": 2, "Doc": "Cheetahs are the fastest land animals, reaching speeds over 60 mph."},
    ],
)

client.query(
    table_name="MyTable",
    query_text="Celestial bodies and their characteristics",
    limit=2
)

The response is a dictionary with a message, a status code and a result list, and the result entries carry the requested fields. The example query returns the Jupiter record and the Moon record, with the Moon entry appearing even though only the first two records were inserted in the shortened snippet, which shows that the full example inserted five records and the search picked the two that matched the text. The text query goes through the built-in embedding support, so the natural language string is turned into a query vector on the server side rather than by the client.

The native library route, marked experimental

There is a way to use Epsilla without a container, and the documentation is careful to mark it experimental. The first stage builds the Python bindings as a shared library, and the steps are a shell script for the oatpp modules and a build script:

cd engine/scripts
bash install_oatpp_modules.sh
cd ..
bash build.sh
ls -lh build/*.so

The second stage runs the test with the built library on the Python path and a database path set:

cd engine
export PYTHONPATH=./build/
export DB_PATH=/tmp/db33
python3 test/bindings/python/test.py

The in-process API mirrors the client API but returns a code and response pair from the query, and it takes a query vector directly rather than text, along with a filter string and a flag for including distances. The example table here has a vector field with a data type of VECTOR_FLOAT, four dimensions and the EUCLIDEAN metric, and the filter argument is a small expression such as ID < 6. So the in-process route is the one to use if you want vector search inside a Python process, and the container route is the one to use if you want a service.

The performance claim, and what the index actually is

The technical claim is that the core is written in C++ and leverages advanced academic parallel graph traversal techniques for vector indexing, achieving ten times faster vector search than HNSW while maintaining precision levels of over 99.9 percent. The comparison to HNSW is the interesting part, because HNSW is itself a graph index, so the claim is not that a graph beats a flat index, it is that a different way of doing the graph beats the usual way. The readme is at least explicit that this is the project's own framing, and a reader should treat the factor of ten as a vendor claim that needs reproducing on their own data and their own recall target. The precision figure is the more useful half of the claim, because a search that is fast but inaccurate is not useful, and 99.9 percent recall is a statement about what the traversal gives up. The rest of the feature set describes how it fits into a system, with cloud native architecture with compute storage separation, serverless and multi-tenancy, and rich ecosystem integrations including LangChain and LlamaIndex, plus Python, JavaScript and Ruby clients and a REST API interface. There is also a fully managed vector database as a service offered separately.

Editorial conclusion

Epsilla suits a team that wants a vector database with a familiar relational shape and hybrid dense and sparse retrieval, and that is comfortable running a container rather than a hosted service. It does not suit a project that needs the vector index to be a drop-in for an existing library, since the retrieval model is the project's own, and the performance claim is the vendor's own rather than an independent measurement. Before you adopt it, read the build steps for the native library bindings, because the experimental in-process route needs a build toolchain rather than a wheel, and check the release tags, since the newest tagged version predates the most recent commit by more than a year.

Frequently asked questions

Official sources

1. epsilla-cloud/vectordb on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases