# RushDB: Database for AI

> RushDB is a self-describing, graph-native database that helps AI agents reason over data with confidence: progressively introspect what's queryable—without guesswork.

Canonical URL: https://rushdb.com/
Last updated: 2026-10-30

RushDB is an open-source database for AI: write JSON, get linked records with a schema catalog updated on every write, and query them with SQL, Cypher, Gremlin, Mongo-style documents, and hybrid vector + BM25 search. One Rust binary (Apache-2.0), or managed on RushDB Cloud.

## Why RushDB

### The schema is written down on every write.

There is no `CREATE TABLE`. Each write updates a catalog of fields, types, values and links, with exact counts. When a service starts sending `amount` as text, the catalog shows it.

More: https://rushdb.com/features#catalog

### Filter first. The schema narrows with you.

Schema calls take the same filter as a records query, so fields, values and counts describe only what matched. A search page gets facet counts that agree with the results on screen, from one query document.

More: https://rushdb.com/features#catalog

### Nested JSON in, linked records out.

Send documents as your apps and pipelines produce them. Each nested object becomes its own record, linked to its parent, in the same commit.

More: https://rushdb.com/features#records

### Records, links, vectors and text in one commit.

Vector and full-text indexes live next to the records and relationships, so there is no second store to keep in sync. Search, traverse and filter in one request.

More: https://rushdb.com/features#architecture

### Smaller models stop guessing.

When every query is checked against what is actually stored, a small open model makes up fewer values than one several times its size, and stays right after the data changes.

- **100×** fewer made-up filter values. Questions with an invented value: 21.3% → 0.2%.
- **0** stale answers after the data changed. Questions using an outdated value: 48% → 0 (8B) · 10% → 0 (4B).
- **4.6×** more right answers on changing data. Correct answers after a rename: 8.1% → 37.1%.
- **50×** fewer made-up values than a 3.5× larger model. Questions with an invented value: 0.4% (4B, RushDB) · 19.9% (14B).

Measured with open models (Qwen3 8B and 14B, Qwen3.5 4B) running locally on BIRD Mini-Dev, 498 text-to-SQL questions, and a set with renamed values, scored automatically against reference answers. Gains are largest on smaller models; large hosted models make few of these mistakes to begin with.

### Look, narrow, look again.

How an agent answers "Why did enterprise customers cancel after the March price change?" on RushDB (example data):

1. **Read the shape** (avoids guessing tier or Enterprise)

```json
{
  "kind": "schema",
  "query": { "labels": ["Customer"] }
}

{
  "kind": "propertyValues",
  "property": "plan",
  "mode": "topK",
  "query": { "labels": ["Customer"] }
}
```

   → Customer · 1,204 records · 38 fields
   → plan: free 803 · pro 189 · enterprise 212
   → canceled_at: datetime · OPENED → Ticket

2. **Narrow on values that exist** (avoids a query that fails on a missing field)

```sql
SELECT count(*) FROM customer
WHERE plan = 'enterprise'
  AND canceled_at >= '2026-03-01'
```

   → 31 customers

3. **Read the shape of what matched** (avoids sampling rows into the context window)

```json
{
  "kind": "schema",
  "query": {
    "labels": ["Customer"],
    "predicate": {
      "plan": "enterprise",
      "canceled_at": { "$gte": "2026-03-01" }
    }
  }
}
```

   → cancel_reason on 31 of 31: price 14 · missing_sso 9 · migrated 8
   → OPENED → Ticket: 47 relationships

4. **Ask the precise question** (avoids an answer built on a field it never checked)

```sql
SELECT c.cancel_reason,
       count(DISTINCT c.__id) AS customers,
       count(e.__id) AS tickets
FROM customer c
LEFT JOIN rushdb_edges.opened e ON e.__source_id = c.__id
WHERE c.plan = 'enterprise' AND c.canceled_at >= '2026-03-01'
GROUP BY c.cancel_reason
```

   → price 14 · 22 tickets
   → missing_sso 9 · 19 tickets
   → migrated 8 · 6 tickets

- **Precise filters.** Every value in a filter came from the database, so `enterprise` is never typed as `Enterprise`.
- **Exact, not sampled.** Counts and values cover every record, so the rare value a question asks about is there to find.
- **Current after a change.** The catalog updates on every write, so an agent filters on today’s values, not a snapshot’s.

## Use cases

### Agent memory: Agents that remember, and can show where a memory came from.

Memories are ordinary records linked to the turn that produced them, so recall returns a source, not just a similar sentence. Scope them by user, agent or session with plain fields.

Example question: "What did Dana decide about the Q3 launch?"

Answer: Dana moved the launch to Oct 2 and asked to brief sales first (session of Aug 14).

```searchquery
{
  "kind": "query",
  "query": {
    "kind": "hybrid",
    "query": {
      "labels": [
        "DECISION"
      ],
      "predicate": {
        "USER": {
          "name": "Dana"
        }
      },
      "text": {
        "index": "decisions",
        "query": "Q3 launch"
      },
      "vector": {
        "property": "embedding",
        "index": "decision-embedding",
        "vector": [ /* query embedding */ ]
      },
      "limit": 3
    }
  }
}
```

More: https://rushdb.com/use-cases#memory

### Company brain & RAG: Answers that span your docs, CRM, support, billing and code, with the record behind every fact.

Each source lands in its own shape and is linked on keys it already shares, like an email or a Stripe customer ID. The agent reads the catalog first, so it knows which source holds what before it asks.

Example question: "What is behind Acme’s recent support escalations, and who should own the follow-up?"

Answer: 

```link on keys
{
  "kind": "linkRecords",
  "command": {
    "relationType": "BILLED_AS",
    "source": {
      "label": "ACCOUNT",
      "property": "stripe_customer_id",
      "predicate": {}
    },
    "target": {
      "label": "INVOICE",
      "property": "customer",
      "predicate": {}
    },
    "direction": "out"
  }
}
```

More: https://rushdb.com/use-cases#company

### AI search & assistants: Search and assistants on the records your app already writes.

Declare text and vector indexes once and the database keeps them current as your app writes, so there is no separate search engine to sync. Filters, facets and ranking run in one query.

Example question: "Waterproof trail shoes under $150, well reviewed"

Answer: 21 products ranked by review match, with facets for the filter UI.

```searchquery
{
  "kind": "query",
  "query": {
    "kind": "hybrid",
    "query": {
      "labels": [
        "REVIEW"
      ],
      "predicate": {
        "PRODUCT": {
          "price": {
            "$lt": 150
          },
          "category": "trail"
        }
      },
      "text": {
        "index": "reviews",
        "query": "waterproof"
      },
      "vector": {
        "property": "embedding",
        "index": "review-embedding",
        "vector": [ /* query embedding */ ]
      },
      "limit": 25
    }
  }
}
```

More: https://rushdb.com/use-cases#apps

### Analytics: Questions about your data, answered by a read-only query you can inspect.

The agent reads real labels, fields and value counts before it writes a query, so it doesn’t invent columns. Every answer comes with its read-only query, so anyone can check the number.

Example question: "Which regions had the most late shipments last month?"

Answer: EMEA 42, North America 17, APAC 9. The query is attached so you can check it.

```sql
SELECT region, COUNT(*) AS late
FROM shipment
WHERE delivered_at > promised_at
  -- datetimes are epoch milliseconds in SQL
  AND to_timestamp_millis(delivered_at)
      >= TIMESTAMP '2026-09-01'
  AND to_timestamp_millis(delivered_at)
      <  TIMESTAMP '2026-10-01'
GROUP BY region
ORDER BY late DESC;
```

More: https://rushdb.com/use-cases#analytics

## Install

One Rust binary. Start a local node:

```sh
curl -fsSL https://rushdb.com/install.sh | sh && rushdb up
```

Also: `brew install rush-db/tap/rushdb`, `docker run -p 127.0.0.1:3000:3000 -v rushdb:/data -e RUSHDB_TOKEN=change-me rushdb/rushdb`.

Or give your coding agent this prompt:

```text
Set up RushDB as this project's database.

1. Install the RushDB MCP server (@rushdb/mcp-server) and the RushDB agent skills (github.com/rush-db/skills).
2. Use RushDB Cloud with an API key from app.rushdb.com, or a local engine:
   curl -fsSL https://rushdb.com/install.sh | sh && rushdb up
   (direct mode: engine URL http://127.0.0.1:3000, token local-token)
3. Before writing any query, read the schema catalog (labels, properties, types, relationship shapes) and use only fields that exist.
4. Docs: https://docs.rushdb.com/3.x/
```

## What teams have built

> 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.
> — Ben Gauthier, Founder & CEO, Billboardbug

Billboardbug: Routing agents that keep their context across sessions

> 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.
> — Andrei Bâcu, Founder, Antifragile AI

Antifragile AI: Compliance answers that trace back to one evidence chain

> 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.
> — Harsha Valluri, Founder @ SymboSystems | Sr. AI Engineer

SymboSystems: Autonomous operations agents that reason over business events

## Questions developers ask first

### What does “Database for AI” mean?

RushDB is a database: it stores records, relationships, and search indexes, with transactions and durable storage. “For AI” means two things it does for agents. Every write updates an exact catalog of labels, fields, types, values, and relationship shapes. And the same catalog can be read for just the records a filter matches. An agent can check both before it writes a query.

### What data can I put in?

JSON from your apps, pipelines, or agents: nested documents, arrays of records, events, and payloads whose shape changes over time. Types are inferred per value and nested objects become linked records, so there is no schema to declare or migrate first.

### Do I have to commit to a model or agent framework?

No. RushDB stores data, not prompts. Any model or framework can use it through the TypeScript and Python SDKs, the MCP server, or HTTP, and a self-hosted engine also speaks SQL over the PostgreSQL wire protocol. Changing models does not move your data.

### Is it a vector database?

It includes vector search (exact and HNSW), BM25 full-text search, and hybrid search that fuses both, but the vectors live on ordinary records with typed fields and relationships. One query can filter, traverse, and rank instead of syncing a copy into a separate vector store.

### What is the difference between the engine and RushDB Cloud?

The engine is the open-source database (Apache-2.0, one Rust binary) that you self-host. RushDB Cloud runs the same engine for you and adds managed embeddings, natural-language search, relationship suggestions, hosted MCP with OAuth, and team access. On a self-hosted engine you bring your own embedding vectors.

### Do I need to replace PostgreSQL?

No. Keep Postgres for stable relational workloads that rely on its constraints, extensions, and ecosystem. Use RushDB for the data your agents and AI features read and write, especially when its shape keeps changing and relationships matter.

### Does schema awareness make agent queries correct?

It removes structural guesswork (which labels, fields, values, and relationships exist), not business-semantic errors. The catalog does not know what “active customer” means at your company. Keep read-only credentials and review the queries an agent writes.

### I used RushDB 2.x. What changed?

2.x ran the API on top of Neo4j. Since 3.0, RushDB is its own Rust engine, and RushDB Cloud runs it with one engine tenant per project. 2.x is preserved at the v2 tag, and the docs include an upgrade guide.

## Next

- Features: https://rushdb.com/features
- Use cases: https://rushdb.com/use-cases
- Pricing: https://rushdb.com/pricing (Markdown: https://rushdb.com/pricing.md)
- Docs: https://docs.rushdb.com/3.x/