TriDB Wiki
A tri-modal retrieval demo · all of Wikipedia, served by an offline reader

A private Wikipedia demonstrating TriDB's tri-modal model — vector similarity, graph traversal, and relational filters in one query. This full-corpus demo is served by an offline reader (SQLite metadata, NumPy CSR link graph, cuVS CAGRA vectors); the Postgres-native TriDB engine — one process, one write-ahead log — is measured at 200K articles graph-inclusive and 1M vector-only. Search by meaning, walk the link graph, find the path between any two topics, ask questions.

Enter the wiki →  ·  no keyword needed — it understands meaning
Vector — similarity Graph — traversal Relational — filter

Why Wikipedia is the demo corpusThe perfect tri-modal proving ground.

A database that unifies similarity, traversal, and filter needs data that is all three at once. Wikipedia is exactly that — and at a scale that makes the fusion matter.

Meaning

Every article is text — an embedding. "Find articles like this one," not just string matches.

Links

~6.9M articles woven by hundreds of millions of hyperlinks — a link graph to traverse and path-find (a NumPy CSR adjacency in this reader).

Structure

Infobox facts, categories, lengths, in-degree — relational predicates to filter and rank by.

Wikipedia exercises the fusion at 6.9M articles in this offline reader; the native engine's largest graph-inclusive measurement is 200K articles (vector leg: 1M). The next proving ground is Wikidata — ~110M entities joined by ~1.5B typed statements, ~16× larger, and edited millions of times a day (a live consistency workload). See the roadmap ↗

Official Wikipedia vs the TriDB WikiSame articles. A different engine underneath.

This isn't a faster way to load a page — Wikimedia's global CDN is excellent at that. It's a knowledge engine: things the official reader can't do in one step, done in one fused query.

Capability Official Wikipedia TriDB Wiki (offline reader)
Article page deliveryGlobal CDN — needs a network round-tripLocal / offline — zero network RTT on the host
SearchKeyword full-text (Elasticsearch)Full-text + semantic vector similarity
Related articles"What links here" — raw link listFused vector + graph, relevance-ranked, early-terminating
Path between two topicsNot built inShortest-path ("Connect") — BFS over the reader's NumPy CSR adjacency
Ask a question (RAG)Not availableGraph-aware RAG over the articles
Structured filtersNot in the readerRelational predicates — in-degree, length, category
Cross-modal update consistencyn/a (single modality)One WAL, atomic — 0 torn vs 42 across a 3-store stack (native engine measurement)
Private & offlinePublic, online onlySelf-hosted, private, fully offline
Scale demonstrated~6.9M (English)Reader: 6.9M today → Wikidata 110M next · native engine: 200K graph-inclusive, 1M vector
On raw speed: we don't claim to out-serve Wikipedia's cached HTML. Where TriDB wins is the knowledge query — semantic related, multi-hop paths, fused RAG. On the 1,490-paragraph HotpotQA host reference corpus (not this wiki), the streaming fused operator matched a blocking oracle's recall while examining ~0.71% of that corpus. A real page-load and search head-to-head will be measured and posted here, not asserted.
⚖  Try it live — Compare keyword vs tri-modal search →
runs the same query both ways over the same 6.9M-article corpus — see what a keyword index can’t surface

Measured, not assertedThe native engine, in numbers — each at its measured scale.

0 vs 42
Torn cross-modal writes under injected failure — one transaction vs three independent stores (native engine).
+15.6 pts
Multi-hop joint recall@5 when the graph leg injects source-anchored context into retrieval (HotpotQA).
~0.71%
Share of the 1,490-paragraph HotpotQA host reference corpus examined while the streaming fused operator beat a full blocking oracle on recall.