Records
Facts, events, entities, decisions, and application state.
Context infrastructure
One shared context layer for software that needs to understand and use operational data.
Agents, applications, and analytics need the same operational data, but most stacks split it across databases, caches, vector stores, graph logic, and synchronization pipelines.
Context is data plus the structure required to use it correctly. RushDB keeps records, properties, values, relationships, embeddings, and live schema together in one queryable context layer.
A precise definition
Context is more than retrieved text.
A useful context layer preserves the record, its actual fields and values, its connections, its semantic representation, and the live structure software needs to query it responsibly.
Properties and values
The fields that exist, their types, and the domains they contain.
Relationships
Explicit connections and paths between operational records.
Semantic representations
Chosen values indexed for retrieval by meaning.
Live schema
A queryable description of labels, fields, values, and relationship paths.
Shared substrate
Write once. Use the context everywhere.
The differentiation is not three unrelated product modes. The same records, schema, values, relationships, and embeddings remain available to three kinds of software consumer.
Agents reason and recall
Inspect structure, retrieve semantically, traverse relationships, and act on durable state.
Applications operate
Read, write, filter, transact, search, and render interfaces against current connected records.
Analytics explains
Aggregate values, inspect change, and connect metrics to the operational evidence behind them.
One fixture · three consumers
Follow the same context from write to use.
This small checkout fixture makes the category concrete. One nested write creates operational records and explicit parent-child structure. Applications query it directly; agents can ask for it through Smart Search; analytical views aggregate the same EVENT records without a copied model.
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.
03 · Agent read
Generate and execute SearchQuery from natural language.
Smart Search uses the project schema, returns the generated SearchQuery and warnings, then exposes the same record result through the SDK envelope.
Request
result = db.ai.search(
'Show open incidents connected to Acme Corp'
)
print(result.search_query)
print(result.warnings)
print(result.data)What to notice
- ai.search is natural-language query generation and execution—not direct vector similarity.
- Inspect searchQuery and warnings before trusting the execution; generated structure varies with schema and model configuration.
How a context layer differs from adjacent infrastructure.
| System | Primary job | Context-layer difference |
|---|---|---|
| Application database | Own operational records and transactions | Adds shared semantic, relational, schema-discovery, and analytical access where the workload needs them. |
| Vector store | Rank embeddings by similarity | Keeps searchable values attached to typed records, relationships, and live structure. |
| Memory framework | Help an agent store and recall context | Makes the same context usable by applications and operational queries, not only an agent runtime. |
| Warehouse | Historical analytical processing and BI | Keeps relationship-aware analysis close to current operational records rather than replacing the warehouse. |
When RushDB fits.
Strong fit
- Data changes shape as the product evolves
- Relationships materially change retrieval or decisions
- Exact filters and semantic search must coexist
- Agents need to inspect operational data before querying
- Applications and analytical views need the same current records
- The team wants to avoid separate graph, vector, and synchronization infrastructure
A specialized system may fit better
- Simple CRUD with a stable relational schema and no semantic or connected-data workload
- A high-frequency financial ledger already well modelled relationally
- Pure blob or object storage
- A replacement for a mature warehouse and its historical BI estate
- Static vector similarity over a small document corpus
- Only ephemeral chat history with no durable operational use