NEXUS vs Pinecone
A typed knowledge substrate stored as human-editable text under git. Zero vendor bill. Sub-5ms retrieval on ninety-thousand entries.
Different abstraction. Different economics.
If you need auditable, cited, human-editable knowledge retrieval with zero vendor bill and sub-5ms latency, NEXUS beats Pinecone on every axis. If you have millions of unstructured PDFs and no curation appetite, Pinecone is still the fastest way to a demo.
Why we did not pick a vector database
A vector is a lossy compressed fingerprint of text. When your top-k retrieves the wrong chunk, you cannot ask the vector why. When compliance asks 'why did the model tell that patient to take this dose?', pointing at a cosine score does not satisfy an auditor. NEXUS was designed backwards from that failure mode.
Point-by-point
| Dimension | AlifZetta NEXUS | Pinecone (vector DB) |
|---|---|---|
| Data model | Typed entities with typed relations — every fact is inspectable | Opaque high-dimensional vectors — cannot ask why |
| Retrieval determinism | Deterministic — same query → same subgraph | Approximate — top-k can drift with index rebuilds |
| Citation binding | Native — every entity has @source + @evidence | None — post-hoc chunk labelling only |
| Query latency (100k entries) | Sub-5ms via compiled inverted index | 10-50ms depending on tier |
| Storage footprint | ~60 MB for 90k entries + index | ~1-4 GB depending on embedding dimension |
| Monthly cost (Series-A scale) | $0 (runs on your CPU node) | $500-3,500 SaaS + $200-2,000 embedding calls |
| Vendor lock-in | None — plain-text DTL under git | Full — proprietary index format |
| Bilingual / Devanagari | Native — same store, same query path | Requires separate embeddings + tuning per language |
| Human editing | Open the DTL file, edit, git commit | Requires re-embedding + re-indexing pipeline |
| Air-gapped deployment | Yes, one binary | No — SaaS dependency |
The cost-curve delta
Pinecone at Series-A scale: $500-3,500/mo for the SaaS + $200-2,000/mo for embedding calls to keep the index fresh. NEXUS at the same scale: $0. It runs as a Python module inside your existing daemon on your existing CPU box. The delta funds an engineer.
Migration in three commands
- Export your existing corpus — dump the source documents Pinecone indexed. You do not need the vectors themselves; just the source text.
- Convert to DTL — one script converts JSON/CSV/Markdown into NEXUS DTL entries. Add @source and @evidence fields.
- Point your retrieval at the AlifZetta daemon — swap the Pinecone client for one HTTP call. Sub-5ms cited retrieval, no SaaS bill.
Frequently asked
Q. But Pinecone scales to a billion vectors — can NEXUS?
At ninety thousand entries NEXUS uses ~60 MB. At a billion — the vast majority of buyers are nowhere near this — you shard the substrate across multiple nodes or move to a graph database backend. But the interesting empirical fact is that most 'we need a vector DB' buyers actually have under a million records, and NEXUS runs those on a single Ryzen at sub-5ms.
Q. Does NEXUS do semantic similarity?
Yes, but not via cosine similarity in embedding space. LATTICE walks the typed graph from query anchors and returns entities connected by typed relations. Deterministic. Auditable. Not approximate.
Try NEXUS end-to-end
Live at demo.axz.si — bilingual queries against ninety-thousand-plus typed entries with cited sub-5ms responses. No embedding model in the loop.
See the demo → Read the NEXUS cornerstone →