Context infrastructure
Turn operational data into connected, searchable context in minutes—without a separate graph database, vector store, or synchronization layer.
Open sourceCloud or self-hostedTypeScript, Python, REST and MCP
The infrastructure problem
Stop rebuilding the same operational data across the stack.
Conventional stacks copy the same operational data into an application database, a cache, a vector store, and hand-written graph logic—then keep every copy in sync by hand. RushDB replaces that duplication with one queryable model.
Typical stack
Customer
Application DB
profile
sync
Redis
session state
sync
Vector DB
support text
sync
Graph logic in code
order relationships reconstructed
Your code owns:
sync · embed · index · join · retry
With RushDB
CRM customerShopify orderServiceNow ticketApplication event
RushDB
One connected operational model
Relationship
Customer → Order → Paymentplaced · paid_by
Live schema
Customer
country: string
plan: string
totalSpend: number
Semantic search
“customers reporting onboarding issues”
Operational result
$248,500
Q3 spend · 12 orders
One model. One API. No synchronization code.
Quickstart
One dataset. Three workloads. Running in minutes.
Import operational data once, then serve application reads, grounded natural-language requests, and analytics from the same connected model—without copying data into separate stores.
01/
Install
Add the TypeScript or Python SDK and create a client with one project API key.
02/
Write once
Import the operational JSON your product already owns. Nested objects become linked records and update the live schema.
03/
Use it three ways
Serve an application read, a natural-language agent request, and an aggregate from the same records.
install
pip install rushdb
write once · ACCOUNT → TICKET
from rushdb import RushDB
db = RushDB('RUSHDB_API_KEY')
db.records.import_json({
'label': 'ACCOUNT',
'data': {
'accountId': 'acme-42',
'name': 'Acme Corp',
'TICKET': [{
'ticketId': 'ticket-104',
'status': 'open',
'category': 'checkout',
'summary': 'Checkout requests time out',
}],
},
})application query · same records
open_tickets = db.records.find({
'labels': ['TICKET'],
'where': {'status': 'open', 'ACCOUNT': {'accountId': 'acme-42'}},
'limit': 20,
})From input to usable structure
Every write creates more than a record.
Send JSON, CSV, events, documents, or application data. RushDB creates connected entities, relationships, live schema, value domains, and semantic representations through one query interface.
json input
push→
graph — auto-linked nodes
vector embeddings
Query-time structural awareness
Your software should know what its data contains.
Before constructing a query, applications and agents inspect the actual fields, observed values, and relationship paths RushDB exposes—then build grounded filters on top of what they found.
01 /Inspect available fields and types
Software reads the live schema—every label, field, and type stored in the connected model—before writing a filter.
02 /Inspect observed value domains and paths
Software reviews the values actually present and the relationship paths connecting entities, so queries match what the data contains.
03 /Construct grounded filters, traversal, and aggregations
Exact filters, graph traversal, and aggregation operate against inspected structure instead of assumptions.
Natural-language question
“Which enterprise customers in Brazil spent more than $10,000 in Q3?”
Grounded against inspected schema
country = Brazil
plan = enterprise
order.date ∈ Q3
sum(order.total) > 10,000
Discover the data before constructing the query.
Inspectable structure
For product and platform teams
Start with the workflow you are building today.
Choose the product problem in front of you. Each workflow uses the same connected operational model while search, relationships, schema, and query surfaces adapt to the task.
Persistent context
Decisions, tool outputs, and entities survive across runs as reusable records.
Semantic recall
Recall prior work by meaning, scoped to a session, agent, or task.
Shared state
Multiple agents read and write the same durable memory graph.
Field notes
Connected context in real systems.
See what data entered, what connected context RushDB created, and which agent, application, or evidence workflow consumed it. Quotations remain the customer's own words; proof labels make the underlying architecture explicit.
Nested JSON → connected graph → developer workflow
“In a few minutes, RushDB can go from Docker Compose to Python SDK to nested JSON turning into a real graph. For developer education, that matters: builders can see the data land in the visualizer and Neo4j Aura, not just read about it.”
Fractional DevRel | Video-First Developer Content & Community Growth | ex-Neo4j
25,062+ routing events → shared agent and application context
“Our agents and our zone grid run on 25,062+ behavioral routing trips, context that has to persist and connect, not reset every session. RushDB gives Billboardbug that memory layer out of the box. The agent remembers, so it moves.”
Founder & CEO, Billboardbug
Controls + evidence + versions → traceable GraphRAG
“EU AI Act compliance needs more than static documents. RushDB gives Antifragile AI a graph-backed RAG layer for articles, controls, evidence, versions, and retrieval logs, so every answer can trace back to one evidence chain.”
Founder, Antifragile AI
Triggers + decisions + outcomes → autonomous operations
“Event-driven autonomous operations need memory that connects every trigger, decision, entity, and outcome. RushDB gives agents a graph-native layer for turning business events into context they can reason over and act on.”
Founder @ SymboSystems | Sr. AI Engineer
Deployment
Cloud, self-hosted, or embedded.
Start on the managed service, deploy into infrastructure you control, or discuss an embedded distribution—without changing the API or connected data model.
Adopt RushDB without replacing the systems that already work.
Primary backend
Let RushDB own evolving operational records when relationships, semantic retrieval, and transactions are central to the product.
Shared context layer
Keep existing systems of record and send RushDB the connected data multiple workloads need to share.
Managed cloud
Create a free project and start through the hosted API without operating infrastructure.
External DB or self-hosted
Connect RushDB Cloud to your Neo4j or Aura database, or run the open-source platform and database yourself.
Embedded or OEM
Package RushDB inside a product with dedicated deployment, governance, and commercial support.
Self-host in one commandDocker Hub →
docker run -p 3000:3000 \ --name rushdb \ -e NEO4J_URL='neo4j+s://your-instance.databases.neo4j.io' \ -e NEO4J_USERNAME='neo4j' \ -e NEO4J_PASSWORD='password' \ rushdb/platform
Pricing
Start free. Move to production when you are ready.
Standard reads are free. Writes are usage-based, with a managed path from prototype to production and dedicated infrastructure for larger deployments.
Prototype
Free
Build and validate your first workflow without a credit card.
100K KU/month · full REST API and SDKs · cloud or self-hosted
Production
From $24/month
Run applications and agents with managed usage and predictable overages.
1M KU/month · free standard reads · production projects and team access
Platform
Talk to us
Use dedicated, governed, embedded, or high-volume infrastructure.
Dedicated cloud or self-hosted · private networking · SLA · migration · OEM
Usage example: one record with 10 properties, two relationships, and one embedding uses approximately 16 KU.
View detailed usage pricing →FAQ
Know where RushDB fits before you build.
Direct answers about adoption, existing databases, adjacent products, production use, and billing.
Both deployment patterns are supported. Use RushDB as the primary backend when it can own connected, evolving operational records. Use it as a shared layer when records still originate in PostgreSQL, MongoDB, object storage, or other systems of record.