AI-powered apps
Add AI features without adding another pipeline.
A new AI feature typically means storing PRODUCT records in one database, copying descriptions into a vector store, and writing a sync job to keep them aligned. RushDB stores the same catalog or event records, indexes the description field once, and answers a plain-English query like "compact warm light for a home office" filtered by fields such as availability — all from the data you already wrote, without a second backend.
RushDB for AI-powered apps is a single backend that stores evolving PRODUCT-style records, indexes chosen text fields for semantic search, and queries relationships, replacing the separate vector store and sync job a new AI feature usually requires.
A new AI feature often creates a second backend.
Product data starts in an operational database, descriptions get copied into a vector store for semantic search, and recommendation logic ends up assembled in application code that stitches the two together. Every schema change to PRODUCT now means updating a sync job too, and if that job lags, search results and recommendations drift out of step with the catalog customers actually see.
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.
Catalog records like the desk-lamp PRODUCT example — sku, category, available, description — write directly into RushDB without predefining every future field, and a managed index on PRODUCT.description makes that text searchable as soon as records land. Structured fields like category and available sit beside the indexed text, so a query can combine "compact warm light" with a strict availability filter in one call.
01
Normalize as catalog data lands
RushDB infers types for sku, category, available, and description on each PRODUCT record without a schema defined in advance.
02
Auto-link nested structure
Nested variant, pricing, or inventory objects under a PRODUCT payload become traversable child records automatically on import.
03
Enrich scattered catalog sources
Suggested-relationship analysis can surface links between products sharing a category or co-purchased in the same order history.
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.
from rushdb import RushDB
db = RushDB('RUSHDB_API_KEY')
db.ai.indexes.create({'label': 'PRODUCT', 'propertyName': 'description'})
db.records.create_many(
label='PRODUCT',
data=[{
'sku': 'desk-lamp-01',
'category': 'lighting',
'available': True,
'description': 'Warm adjustable desk lamp for a small workspace',
}],
)
products = db.ai.search({
'labels': ['PRODUCT'],
'propertyName': 'description',
'query': 'compact warm light for a home office',
'where': {'available': True},
})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.
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.