RustyRAG

RustyRAG is aimed at a specific pain: retrieval that is fast enough that a user doesn't notice it happened. The entire pitch is the 300 ms p50 number, and the site is unusually explicit about how it gets there — a stack written in Rust (no Python overhead), inference hosted on Cerebras and Groq, and retrieval, reranking, and citation assembly run in parallel rather than in sequence. The site's own race animation breaks one call into 30 ms retrieve, 150 ms first token, 300 ms total, and lets you compare 1, 10, or 100 sequential loops against Vendor A, Vendor B, and a DIY stack. That framing matters because agent loops compound: a 300 ms call run ten times in a row stays inside a conversation, a 1.3 s call does not.\n\nWhere it looks strongest is the turnkey path. The five layers the site enumerates — realtime retrieval, connectors and ingestion, shared collections, integration, observability — are exactly the pieces teams normally stitch together from a vector database, an embedder, a reranker, a parser, and an eval tool. Ingestion reads uploads, Google Drive, OneDrive, SharePoint, and web crawls, auto-refreshes when source documents change, and handles PDFs, scans, tables, forms, and code with layout-aware parsing plus OCR. The index is genuinely hybrid: 1536d cosine HNSW vectors alongside BM25 for exact terms, with metadata filtering, tenant isolation, and encryption at rest, then a cross-encoder reranking the top candidates before dedup and citation. You reach it via TypeScript, Python, an MCP server, or plain REST, and the site's own estimate is under ten minutes if your team can call an API. Shared collections with role-based access and one-click revoke, plus per-workspace usage, cost attribution, and query replays, are the features a legal or audit team will actually ask about.\n\nThe honest weaknesses are the benchmark and the buying model. The 10k-document corpus is a fair size for many products but a small sample for anyone indexing tens of millions of chunks, the competitors are unnamed, and the numbers come from the vendor. Pricing is quoted rather than published — the site lists a Usage-based plan and an Enterprise plan, both marked Custom — so you cannot model total cost from the public pages, and the only hard number anywhere is the $0.18 per 1k queries used in the benchmark comparison against $0.80 DIY (both from the seed data). The public pages also don't expose chunking strategy or embedding choice, so if your retrieval pipeline is a competitive asset or your stack has standardized on a particular LLM, this is the wrong layer. Treat it as a fast managed retrieval layer, test it on your own corpus, and negotiate the contract with your own query volume in hand.