NuclaDB
Vector Search Engine, Built From Scratch
A vector database written from scratch in Go: HNSW indexing, a crash-safe write-ahead log, mmap-backed snapshots, and tenant-isolated multi-tenancy with scoped API keys. Product quantization and a Raft-sharded cluster exist as tested packages. Benchmarked head-to-head against a real Qdrant instance, not wrapped around one.
// why this exists
Most vector database side projects wrap an existing engine, like Qdrant, Pinecone, or pgvector, behind an app and call it a day. NuclaDB goes the other direction: the graph index, the durability layer, and the compression are the actual project, implemented and benchmarked against a real Qdrant instance rather than imported from one.
// numbers, not adjectives
Recall & throughput vs. Qdrant, 10K-vector SIFT, same machine, median of 5
| ef | NuclaDB recall@10 | Qdrant recall@10 | NuclaDB QPS | Qdrant QPS |
|---|---|---|---|---|
| 10 | 0.932 | 0.959 | 13914 | 7624 |
| 50 | 0.996 | 0.998 | 10653 | 7051 |
| 200 | 1.000 | 1.000 | 5822 | 5512 |
Build time & memory, 10K vectors
| Backend | Build time | RSS after build |
|---|---|---|
| NuclaDB | 416ms | 45.7 MB |
| Qdrant | 557ms | 115.4 MB |
Concurrent load over gRPC, ef=100, recall@10 0.99
| Connections | Searches/s | p50 | p99 |
|---|---|---|---|
| 1 | 4305 | 0.24ms | 0.35ms |
| 32 | 22390 | 1.2ms | 5.4ms |
| 128 | 25752 | 3.5ms | 28.5ms |
// how it's built
Durability Layer
- fsync'd write-ahead log before every acknowledged write
- Group commit and a parallel build: 10K vectors in 416ms, down from 43.9s
- Snapshots every 5 min: restart in 5ms vs 300ms of WAL replay
Indexing & Compression
- HNSW with the paper's diversity heuristic for neighbors
- ef_search chosen per query
- Product quantization: 16x smaller, 99.3% recall with re-ranking
Multi-Tenancy & API
- Per-tenant graph, WAL, snapshot, dimension and metric
- Quotas, token-bucket rate limits, scoped API keys, TLS
- gRPC + REST + CLI + Python client