8.9B
Genetic variants
232
Annotations each
<10ms
Lookup latency
25x
Data compression
30TB to 1.2TB
FAVOR is not one system with one shape of query. It is a small collection of engines, each built for one access pattern. These are the patterns the platform has to serve.
Point lookups at billion scale
Any variant, any annotation, answered in milliseconds. Bloom and ribbon filters skip misses without touching disk.
Batch multi-get at streaming throughput
Pipelined, pre-sorted point lookups at around 10,000 variants per second per instance. Random reads become sequential reads, and batch uploads scale horizontally from there.
Range scans over sorted coordinates
A region query like chr17:43,000,000-43,200,000 is a single sequential read, because everything is sorted by chromosome and position. Powers the genome browser, gene pages, and the region explorer.
Interval overlap queries
Which regulatory elements overlap a variant. Which credible sets contain a position. Which genes a region falls inside. A variant resolves against thousands of intervals in one indexed step.
Columnar scans with predicate pushdown
Aggregate a few columns across the full genome without reading the rest. Filters and bounds get pushed to the storage layer, so it only touches the fields and row groups the query needs.
Top-K ranked retrieval
Rank a variant list by any numeric annotation and return the top ten, without sorting every row. Powers variant prioritization, search ranking, and the most-relevant views on gene and region pages.
Materialized aggregates
Gene-level variant density, per-tissue signal averages, regional constraint scores. Precomputed at release time, so a gene page never scans billions of rows at request time. Storage traded for latency.
Full-text, fuzzy, and vector search
Three layers over the same entity index. Exact and alias matches first, then typo-tolerant fuzzy matching, then vector similarity on entity embeddings for meaning matches a string search cannot catch. Every result carries a confidence tier.
Graph traversal and pattern matching
BFS, shortest path, Jaccard similarity, centrality, enrichment, and subgraph pattern matching against a biomedical network. Runs in the same process as the API, so multi-hop queries do not pay a network round-trip per hop.
Scatter-gather and pub-sub
A single variant page fans out across several databases at once. RocksDB returns the 232 annotations. Kuzu walks the surrounding genes, diseases, and drugs. ClickHouse pulls overlapping cCREs, enhancer-gene links, chromatin states, tissue signals. Others join when the page needs them. All run in parallel; the API waits for the slowest and merges the results.
The platform is a handful of components with strict rules about what each one is allowed to talk to. The rules matter more than any single component: they are what keep failures local and what let any one part be rewritten without touching the others.
Web frontend
Renders the portal: entity pages, region views, the batch annotation workspace, and the agent chat. Owns no data. Every read goes through the API.
Built with Next.js, React, TypeScript, D3, WebGL
API layer
The only thing that talks to storage. Handles routing, auth, request parsing, and the scatter-gather across serving engines described above. Web, CLI, and agent all go through here. This is also where cross-engine joins happen.
Built with Rust, Tokio, Arrow, gRPC, REST, SSE, NATS
Storage layer
A Parquet lake on object storage is the source of truth. Several serving engines sit in front of it as materialized views, each tuned for one access pattern: point lookup, columnar scan, full-text, vector similarity, graph traversal, and a transactional path for user data.
Built with RocksDB, ClickHouse, Kuzu, PostgreSQL, Elasticsearch, Parquet, Roaring bitmaps
Batch workers
Long-running jobs do not run inside the API process. They run in a worker pool that pulls from a message bus, processes in parallel, and writes results back. Batch annotation, enrichment, and analytics runs all land here.
Built with Rust, NATS, DataFusion, Arrow, Parquet
CLI
A second path into the platform for users who need to run analyses on their own hardware, on HPC, or inside protected hospital infrastructure where the web portal is not an option. Reads the same Parquet data the web path reads.
Built with Rust, DataFusion, Arrow, Parquet, Nextflow
Agent runtime
Sits between a user question and the rest of the platform. Plans a step, calls a tool through the API, checks the result, and either continues, retries with a fix, or asks a precise question.
Built with Python, TypeScript
No single database handles every access pattern well
Point lookup, columnar scan, full-text search, and graph traversal are four different storage problems. Each engine owns the one it is good at. Running several engines is the price we pay for keeping each one simple.
Rust where latency matters, Python and TypeScript where iteration matters
The API and the CLI are Rust. The web platform is TypeScript. The agents are Python and TypeScript. Each language is used where it earns its keep.
The AI agent is a real user of the API, not a wrapper around it
Errors come back with a fix the agent can run directly. Column-name typos get corrected. Ambiguous requests get a precise question back instead of a guess. Improvements to the API benefit both humans and agents.
The public API, portal URLs, documented annotation columns, and the release notes are the stability contract. Everything on this page describes current internals. Components can be renamed, merged, split, or replaced as the platform grows. For user-visible changes, read the release notes.