← Back to siteGraphANN™ — Print Leaflet · A4 · 6 pages
◇GraphANN™
Private beta · 2026 · Edition 01
Storage-efficient vector search

Keep the graph.
Drop the vectors.

Up to 95% less storage at scale. Recall on par with full-precision vector indexes. Hot-swappable models without re-indexing. GraphANN™ keeps a navigable graph of your knowledge base and recomputes the vectors on demand for the small fraction of documents visited per query, so embeddings are never persisted.

95%+less storage at scale *
0raw embeddings persisted
graphann.com·self-hosted·commercial license
02The problem

Vector storage is a tax
you didn't sign up for.

Modern embedding models produce high-dimensional vectors, at 1024, 1536, even 3072 dimensions at full precision. A single billion-document index can consume multiple terabytes of disk before you've added a single byte of source content. Switch models, re-embed everything. Pay your cloud provider. Repeat.

Index sizeDim 768Dim 1536Dim 3072
10 M vectors30 GB61 GB123 GB
100 M vectors307 GB614 GB1.2 TB
1 B vectors3.0 TB6.1 TB12.3 TB
Float32 embeddings only. Excludes graph indices, metadata, source text. Excludes the second copy you keep when migrating models.
  • ~80% of disk in a typical vector deployment is the embedding payload (at dim ≥ 768; lower dims skew this). At scale that's five figures per year before replicas and snapshots.
  • ~3-7× hardware footprint after accounting for RAID, backups, replicas, snapshots.
  • Every model upgrade is an index rebuild. Days of compute. Hours of downtime.
03The solution

Embeddings are derived data.
Treat them like a cache.

You don't have to store the embeddings. They can always be regenerated from the source text with the same model. Store the graph and the source text. Recompute the rest on demand.

1
Embed query
One forward pass through the embedding model, local ONNX, Ollama, OpenAI, or your own.
→
2
Traverse graph
Graph navigation visits only a small fraction of documents, sub-linear in knowledge base size. The graph structure lives on disk.
→
3
Recompute & rank
For just the visited candidates, run a single batched forward pass through the embedding model. Re-rank with exact distances. Return.
Why it works

Graph traversal is sub-linear. Only a small fraction of the knowledge base is visited per query. With a typical embedding model, recomputing those embeddings takes single-digit milliseconds. That's cheaper than streaming gigabytes of vectors off disk.

What's stored

Source text (compressed) and the graph topology. No raw embeddings persist anywhere.

Hot model swaps

Switch embedding models via a background re-embedding job that preserves external IDs and serves live traffic throughout. The index is rebuilt online without downtime.

Recall

Multi-level beam: approximate at scale, exact re-ranking with on-the-fly embeddings on the candidates. Recall on par with full-precision vector indexes.

04By the numbers

Up to 95%+ less storage at scale.
Recall on par with full-precision vector indexes.

Traditional vector DB
6.1TB
1 B vectors @ dim 1536, float32
  • Embeddings on disk
  • Graph on disk
  • Source text on disk
  • Re-embed on model swap
GraphANN™
~180GB
same workload: graph + compressed text
  • Embeddings on disk
  • Graph on disk
  • Source text: zstd compressed
  • Hot-swap models without rebuild

* Storage figure: recompute mode, source text zstd-compressed, dim 768 embedding model. Per-mode breakdown is available on request.

Multi-level beam search
Approximate across the full knowledge base, exact re-ranking on the final candidates. Tunable per index to fit your latency-recall budget.
4 embedding backends
Local ONNX (bge-small embedded), Ollama, OpenAI, and a pluggable interface for custom providers.
SIMD distance kernels
Platform-optimised distance computation on amd64 and arm64. 3–5× faster than a generic implementation.
Live ingestion
Append documents without rebuilding. Tombstone-based deletes. Background compaction to keep recall high.
05Operations

Built for operators.

A vector database that earns its keep on every dimension your operations team cares about: isolation, replication, observability, and predictable upgrades.

⌗
Multi-tenant by design
Tenants, users, role-based access (Admin / Editor / Viewer), per-tenant quotas, and on-disk index isolation. One process serves many customers without leaking metadata between them.
◫
Highly available cluster
Raft-replicated control plane, gossip-based membership, scatter-gather query routing, zone-aware replica placement, and anti-entropy repair. Lose a node, keep serving.
⌬
Backup & restore
Point-in-time snapshot manifests to filesystem or any S3-compatible store (MinIO, R2, GCS, AWS, same code path). Restore to a known good state in a single command, with no index rebuild.
⟳
Hot model migration
Switch embedding models without taking the index offline. Background re-embedding job preserves external IDs and runs against live traffic.
◈
Hardened by default
Optional TLS, mutual-TLS for cluster peers, encrypted gossip, argon2id-hashed API keys, role gates on every mutating handler, and SSRF-safe outbound URL validation. SOC 2 Type II in progress; security overview available on request.
▢
One self-contained binary
Static Go binary with the embedding model bundled inside. Runs on a laptop or a 100-node cluster. No external dependencies, no SaaS lock-in.
06Get started

Ready to drop
the vectors?

GraphANN™ is in private beta. Request a sandbox cluster, sizing guidance, or a technical walkthrough, we'll get back to you with onboarding support within one business day.

Webgraphann.com
Docsgraphann.com/docs
ClientsGo · TypeScript · Python
Accessgraphann.com/contact
“Embeddings are derived data. Treat them like a cache, not like state.”
95%+less storage at scale *
3×–5×SIMD-accelerated distance
3×replication, zone-aware
◇GraphANN™
Private beta · July 2026 · Edition 01