Solution · Applications

Build applications on the same connected context your agents and analytics use.

Name: RushDB
Availability: InStock

Use RushDB as an operational backend for evolving JSON, connected records, semantic discovery, generated facets, workflow state, and AI-assisted product experiences.

RushDB gives applications a durable context layer: exact operational records, relationships, semantic representations, live schema, and analytical query shapes remain available through one API.

Start building Explore the context layer

Adding AI features should not create a second application backend.

A conventional feature stores operational records in one database, copies searchable text into a vector store, rebuilds relationships in code, and adds a synchronization job for every schema change.

Conventional stack

Operational records in an application database
Searchable text copied into a vector store
Relationships and joins reconstructed in code
Separate schema contracts for filters and agents
Synchronization and retry logic owned by the application team

With RushDB

Flexible, typed records for evolving product data
Exact filters and semantic retrieval on the same fields
Explicit, queryable relationships
Live schema for generated filters and agent queries
Transactional updates through REST and SDKs

Implementation walkthroughs

Run the workflow against your own records.

The requests are concrete and copyable. Result values are intentionally not simulated: inspect the records, metrics, generated queries, warnings, and scores returned by your configured project.

01 · Create context

Import one operational fixture with explicit nested structure.

Upper-case nested keys become labels and preserve parent-child relationships. Property types and the schema surface emerge from the records that were actually written.

Request

db.records.import_json({
  "label": "ACCOUNT",
  "data": {
    "accountId": "acme-01",
    "name": "Acme Corp",
    "tier": "enterprise",
    "FEATURE": [{
      "featureId": "checkout",
      "name": "Checkout",
      "EVENT": [
        { "eventId": "evt-1", "type": "conversion", "value": 129, "channel": "organic", "timestamp": "2026-07-25T09:00:00Z" },
        { "eventId": "evt-2", "type": "conversion", "value": 89, "channel": "partner", "timestamp": "2026-07-26T10:00:00Z" }
      ],
      "INCIDENT": [{
        "incidentId": "inc-17",
        "status": "open",
        "severity": "high",
        "summary": "Checkout requests are timing out."
      }]
    }]
  }
})

What to notice

Nesting provides the relationship source in this fixture.
Matching identifiers in unrelated flat imports would remain ordinary fields until explicitly connected.

02 · Application read

Load the open incident and its connected account context.

The application uses an ordinary SearchQuery: exact status filtering at the root and relationship traversal through FEATURE to ACCOUNT.

Request

incidents = db.records.find({
    'labels': ['INCIDENT'],
    'where': {
        'status': 'open',
        'FEATURE': {
            'ACCOUNT': {'accountId': 'acme-01'}
        },
    },
    'limit': 20,
})

What to notice

Inspect total and data on the result returned by your own project; this page does not prescribe their values.
The result is operational data; no vector index or language model is required.

Semantic discovery

Rank text within an exact application scope.

Direct vector search belongs to the records surface. Exact fields narrow candidates before similarity ranking and every returned record carries __score.

Request

matches = db.records.vector_search({
    'labels': ['INCIDENT'],
    'propertyName': 'summary',
    'query': 'payment requests timing out',
    'where': {'status': 'open', 'FEATURE': {'featureId': 'checkout'}},
    'limit': 5,
})

What to notice

summary must have a ready managed or external embedding index; inspect returned scores in your own project.
Use ai.search(prompt) instead when the desired operation is natural-language SearchQuery generation.

Shared primitives

The operational primitives applications need.

These capabilities operate on the same records, relationships, schema, values, and semantic representations used elsewhere in the platform.

Evolving records

Write the JSON shape the product already produces and add fields as the application changes.

Filters and facets

Use typed values, selection, pagination, and schema inspection to power generated interfaces.

Connected queries

Traverse relationships without rebuilding the domain graph after every read.

Semantic discovery

Index chosen text fields and combine similarity with exact application constraints.

Operational metrics

Group, count, and inspect current records without exporting a second model first.

Safe writes

Use ACID transactions for related record and relationship updates.

Example systems

Use one backend for connected product experiences.

Catalogs and marketplaces

Power exact facets, semantic discovery, related entities, and evolving inventory data.

Workflow systems

Keep tasks, approvals, tool output, actors, and outcomes connected through resumable operations.

Investigation tools

Explore entities, evidence, relationship paths, current values, and operational history in one interface.

When RushDB fits application architecture.

RushDB is strongest when data changes shape, relationships matter, exact and semantic retrieval must coexist, and agents or analytical views need the same operational records. A stable relational CRUD system with no connected or semantic workload may be better served by a conventional relational database alone.

Records Search Transactions TypeScript SDK