VortexDB - A vector database built from scratch in Rust 🦀. VortexDB is designed for efficient similarity search and can be used as the backbone for AI-powered applications.
Full documentation lives at vortex-db.sdslabs.co:
- Installation and Quickstart
- Concepts: Architecture, Indexers, Snapshots
- API reference: overview, HTTP, gRPC
- Python SDK: reference and examples
The sources for the site are in docs/.
VortexDB is organized as a Rust workspace with modular crates for flexibility and maintainability.
The indexing layer provides efficient vector similarity search with pluggable index implementations. VortexDB supports Flat indexing for brute-force exact search (ideal for smaller datasets), KD-Tree for space-partitioning in low-dimensional vectors, and HNSW (Hierarchical Navigable Small World) graphs for fast approximate nearest neighbor search on large-scale datasets.
Supported distance metrics include Euclidean, Manhattan, Hamming, and Cosine similarity.
The storage layer abstracts persistence with a StorageEngine trait, allowing different backends. RocksDB offers persistent, production-ready storage for real-world deployments, while InMemory keeps points in process for tests and ephemeral workloads.
RESTful API server built with Axum:
GET / - Root endpoint
GET /health - Health check
POST /points - Insert a point
GET /points/:id - Get a point by ID
DELETE /points/:id - Delete a point
POST /points/search - Search for similar vectors
High-performance gRPC server with Protocol Buffers. Features include:
- Configurable logging
- Full CRUD operations for vector points
Interactive terminal user interface built with Ratatui:
- Dashboard view for database overview
- Database management
- Vector operations (insert, search, delete)
- Modal dialogs for user input
VortexDB offers a Dockerfile and a docker-compose for starting up the gRPC and HTTP servers
Steps to get the unified server running:
cp .env.example .env
The following env vars are important, and are required to be set by the user:
VORTEXDB_KEYS_FILE
DIMENSION
DATA_PATH
NOTE: DATA_PATH is the directory within the container where persistent data is stored
NOTE: VORTEXDB_KEYS_FILE points to a JSON file of API keys shared by both the HTTP and gRPC servers, e.g.:
{
"keys": [
{ "name": "admin", "role": "readwrite", "key": "some-random-secret" },
{ "name": "search-service", "role": "readonly", "key": "another-random-secret" }
]
}Requests authenticate with an api-key: <key> header over HTTP, or an authorization: Bearer <key> header over gRPC. readonly keys can read/search but not insert, batch-insert, or delete; readwrite keys can do all of the above. See keys.example.json.
Setting of the following env vars is optional, as they fallback to safe defaults, but recommended:
| .env Var | Function | Safe Default |
|---|---|---|
HTTP_HOST |
Host IP for the HTTP Server | 0.0.0.0 |
HTTP_PORT |
Port for the HTTP Server | 3000 |
GRPC_HOST |
Host IP for the gRPC Server | 0.0.0.0 |
GRPC_PORT |
Port for the gRPC Server | 50051 |
STORAGE_TYPE |
Store inmemory | rocksdb |
inmemory |
INDEX_TYPE |
Type of Indexer: flat | kdtree | hnsw |
flat |
LOGGING |
Enable logs | true |
DISABLE_HTTP |
Bool flag to run the HTTP Server | false |
NOTE: CLI flags (e.g. docker compose run --env ) take precedence over docker-compose environment values, which in turn override .env file variables.
Now you're all set up.
To run the unified server:
docker compose up
To build the image again and run the unified server (recommended after code changes):
docker compose up --build
To run only the gRPC server (HTTP server disabled):
DISABLE_HTTP=true docker compose up
- InMemory implementation of StorageEngine
- Snapshots for indexers
- Python SDK — sync and async clients (
client/python) - API key authentication for the HTTP and gRPC servers
- Benchmarking suite
- JavaScript/TypeScript SDK
- Modular vectorization service
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.