RAG and knowledge bases
RAG that retrieves connected context.
Search by meaning, then use explicit relationships and filters to bring related records into the answer.
The nearest chunk is not always the missing context.
Flat similarity search can find relevant text while missing the record that explains how it fits your product, customer, plan, or decision history.
Before
- Chunks stored without business context
- Similarity scores as the only retrieval signal
- Relationship lookups in a separate system
- Application-side joins after search
With RushDB
- Text indexed for semantic recall
- Explicit links for known business relationships
- Structured filters beside search
- One backend for retrieval and connected context
Graph intelligence on ingest
Incoming data becomes queryable graph context.
RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.
01
Normalize as data arrives
Import JSON or CSV. RushDB infers property types and adds new fields to the live, queryable ontology without a schema migration.
02
Auto-link nested structure
Nested objects become connected records automatically, preserving the parent-child graph structure already encoded in your payload.
03
Enrich scattered sources
After flat imports or schema changes, analyze the project ontology. RushDB can suggest join patterns and semantic relationship types for your review.
Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.
Review suggested relationship patternsWorking example
Keep the pricing change connected to its announcement.
The application knows when a pricing change was announced in a blog post, so it attaches that relationship explicitly. Semantic search and connected-record queries can then use the same stored data.
PRICING_CHANGE --ANNOUNCED_IN--> BLOG_POST
PRICING_CHANGE --APPLIES_TO-----> PLAN
CUSTOMER_QUESTION --ABOUT-------> PLAN{
"labels": ["DOCUMENT"],
"propertyName": "content",
"query": "Why did Pro pricing change?"
}{
"kind": "pricing_change",
"content": "Pro pricing changed after the usage model update.",
"related": ["Launch notes: usage-based pricing"]
}TypeScript SDK
A complete starting point.
The example includes the one-time index setup so the retrieval path is explicit.
Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
Semantic search
Use semantic retrieval over indexed text while keeping filters, pagination, and graph traversal available.
Open docsRelationships
Model document, author, topic, citation, and provenance links instead of returning only nearest text chunks.
Open docsRelationship API
Attach and inspect explicit relationships when your knowledge graph needs domain-specific edges.
Open docsHow it works
Build the smallest useful workflow first.
01
Ingest useful records
Store documents, chunks, plans, and source metadata in the shape your retrieval flow needs.
02
Attach known relationships
Create links for the domain facts your application already knows, such as authored-by, part-of, or applies-to.
03
Retrieve with context
Use semantic recall, structured filters, and relationship queries without syncing a separate graph layer.
Know where it fits.
Be explicit about links
Nested JSON imports create traversable structure. Domain-specific links should be attached when your application knows them.
Bring your own vectors when needed
Use managed embeddings for convenience or provide vectors from the model and index policy your system requires.