Use cases

Find the right fit.

Six common shapes of work, what each looks like wired up, and where GraphANN™ earns its place, or doesn't. Pick a scenario:

Scenario
Stable documents · low write rate

Internal docs, standards, product manuals

A bounded document library that grows in batches, engineering wikis, policy libraries, regulatory standards, technical reference. High read volume, low write rate.

A large, stable document library costs almost nothing to keep searchable, and you can adopt a better model any time without rebuilding it.

01
Bulk ingest on a schedule
Your pipeline chunks documents and posts them to the bulk ingest endpoint. Rebuilds happen weekly or on document update.
02
GraphANN™ holds the graph + compressed text
No embeddings persisted. Storage scales with your content, not your choice of embedding model.
03
Application queries directly
Search returns ranked passages with source metadata. Drop-in replacement for keyword search or pgvector.
Source corpusPDFs · wiki · standardsperiodic re-indexChunkerparagraph · recursiveGraphANNsingle indexgraph + compressed textno embeddings persistedAppsearch UIqueryresultsSTORAGE FOOTPRINTTraditional vector DB100%GraphANN~3%low write rate · high read · ideal for stable corpora
Best fit when
  • Document library spans thousands to millions of records
  • Updates arrive in batches, not as continuous streams
  • You care about storage cost or model lifecycle, not raw ingest QPS
  • You want to swap embedding models without rebuilding the world
Wrong choice when
  • You need transactional consistency between document writes and search
  • Your document library is already small enough that a simple search works fine
  • You need rich SQL-style joins on document properties at query time
Up to 95%
less storage at scale
Bulk
ingest endpoint
Single
binary deploy
Talk to us

Got a shape that isn't here?

Send us your architecture sketch. We'll tell you honestly whether GraphANN™ is the right tool, or point you to one that is.

Start a conversation →