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.
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.
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.
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.
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.
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.
[01] Why RushDB
Agents see the data’s shape before they query it.
Agents querying live data fail in two ways. They guess field names, types and values that don’t exist, and they can’t see what’s inside a slice of data before they narrow it. RushDB keeps an exact record of every field, type and value as data is written, and lets agents read it for all records or just the ones a filter matches.
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.
Filtered schema queriesNested 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.
How ingestion worksRecords, 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.
ArchitectureSmaller 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-upfilter values
0
stale answers afterthe data changed
4.6×
more right answerson changing data
50×
fewer made-up valuesthan a 3.5× larger model
Look, narrow, look again.
This is how an agent answers a real question on RushDB. It reads the shape of the data, filters on values that exist, then reads the shape of just the records that matched before it asks the precise question. Every field and value it uses came from the database.
- Precise filters
- Every value in a filter came from the database, so
enterpriseis never typed asEnterprise. - 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.
Why did enterprise customers cancel after the March price change?
1Read the shape
// describe { "kind": "schema", "query": { "labels": ["Customer"] } } // query { "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
2Narrow on values that exist
SELECT count(*) FROM customer WHERE plan = 'enterprise' AND canceled_at >= '2026-03-01'→31 customers
3Read the shape of what matched
// describe, same filter as step 2 { "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
4Ask the precise question
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
Open source. The engine is Apache-2.0, one Rust binary.
github.com/rush-db/rushdb[02] Install
One Rust binary. Running in a minute.
No other services to run: the engine, its indexes and its storage ship as a single binary. Native on Linux and macOS (x86-64 and arm64); on Windows through WSL 2 or Docker.
[03] Customers
What teams have built.
Billboardbug
Routing agents that keep their context across sessions
- 25,062+
“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
Agent memoryAntifragile AI
Compliance answers that trace back to one evidence chain
“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
Company brain & RAGSymboSystems
Autonomous operations agents that reason over business events
“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
Agent memory[04] Works with your stack
Built for the stack you already run.
RushDB speaks the Postgres wire protocol on :5432 and Neo4j’s Bolt on :7687. Drivers, SQL clients, BI tools and agents built for them connect as they are. Everything else talks HTTP.
Connect · Postgres wire :5432 · drivers, SQL clients, BI
Connect · Bolt :7687 · graph drivers
Connect · HTTP :3000 · gRPC · services
Agents · MCP, frameworks, SDKs
Query · languages on the same data
Write
1 284 093
- 2.9 ms
- 0.4 ms
- 70 ms
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.
Precision your agents can query.
or