RAG and knowledge bases
RAG that retrieves connected context.
Search DOCUMENT records by meaning, then follow explicit relationships such as ANNOUNCED_IN and APPLIES_TO to bring the plan, announcement, or decision history connected to that chunk into the same answer. Filters and relationship traversal run beside semantic recall in one query, so the retrieval step returns the record that explains the match, not only the match itself.
Graph-aware RAG in RushDB pairs semantic search over indexed DOCUMENT content with explicit relationships like ANNOUNCED_IN and APPLIES_TO, so retrieval returns connected business context, not just the nearest chunk.
The nearest chunk is not always the missing context.
Flat similarity search over PRICING_CHANGE or DOCUMENT chunks can surface text that mentions the right words while missing the BLOG_POST that announced the change or the PLAN it actually applies to. Without a relationship lookup running beside the vector query, the application code has to join that context back together after retrieval, and the answer either omits the connection or requires a second round trip to a separate system.
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.
Incoming records like PRICING_CHANGE and BLOG_POST land as DOCUMENT-labeled records with a content field, and a managed index on DOCUMENT.content makes that text searchable immediately. Relationships your application already knows — PRICING_CHANGE ANNOUNCED_IN BLOG_POST, PRICING_CHANGE APPLIES_TO PLAN — are attached explicitly at write time, so retrieval can traverse from a matched chunk to the record that explains it.
01
Normalize as documents arrive
RushDB infers types for content, kind, and source fields on each DOCUMENT record without a predefined schema to maintain.
02
Auto-link nested structure
Nested document or chunk payloads create traversable parent-child records automatically, preserving source hierarchy.
03
Enrich scattered sources
Suggested-relationship analysis can propose links like ANNOUNCED_IN or APPLIES_TO between documents that reference the same plan or product.
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.
from rushdb import RushDB
db = RushDB('RUSHDB_API_KEY')
db.ai.indexes.create({'label': 'DOCUMENT', 'propertyName': 'content'})
pricing_change = db.records.create(
label='DOCUMENT',
data={'kind': 'pricing_change', 'content': 'Pro pricing changed after the usage model update.'},
)
launch_notes = db.records.create(
label='DOCUMENT',
data={'kind': 'blog_post', 'content': 'Launch notes: usage-based pricing.'},
)
pricing_change.attach(launch_notes, options={'type': 'ANNOUNCED_IN'})
recall = db.ai.search({
'labels': ['DOCUMENT'],
'propertyName': 'content',
'query': 'Why did Pro pricing change?',
'limit': 10,
})Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this blueprint: 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.