AI-powered apps
Add AI features without adding another pipeline.
Store evolving product data, search by meaning, and query relationships from one backend.
A new AI feature often creates a second backend.
Product data starts in one database, embeddings live in another, and recommendation or relationship logic becomes a sync job that has to stay correct.
Before
- Product data in an operational database
- Descriptions copied into a vector store
- Recommendations assembled in application code
- Sync jobs for every model change
With RushDB
- Flexible records for evolving product data
- Managed or external vectors on chosen fields
- Structured filters beside semantic search
- Relationships when the product model needs them
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
Search a product catalog in plain English.
Store catalog records, index descriptions once, and retrieve products using the customer language your application receives.
[
{
"sku": "desk-lamp-01",
"category": "lighting",
"available": true,
"description": "Warm adjustable desk lamp for a small workspace"
}
]{
"labels": ["PRODUCT"],
"propertyName": "description",
"query": "compact warm light for a home office",
"where": { "available": true }
}{
"sku": "desk-lamp-01",
"category": "lighting",
"description": "Warm adjustable desk lamp for a small workspace"
}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.
Import JSON data
Push nested product, customer, event, or app data and let RushDB create records, types, and parent-child structure.
Open docsLabels and properties
Build app UI around discovered labels, fields, values, and record counts instead of hardcoded backend metadata.
Open docsSearch labels
Scope record queries to the right labels before applying filters, sorting, pagination, and relationship traversal.
Open docsHow it works
Build the smallest useful workflow first.
01
Store the product shape you have
Write catalog, event, or application records without planning every future field before the first release.
02
Index selected text fields
Add semantic search to descriptions, notes, or user-generated content without moving the data into another store.
03
Evolve the feature
Add filters and explicit relationships as your product workflow becomes more specific.
Know where it fits.
Use RushDB as a primary backend or alongside one
Choose the adoption path that fits the feature. You do not need to migrate an existing application before testing a focused AI workflow.
Keep validation optional
Start with flexible records, then add model validation where a production workflow needs stronger guarantees.