rushdb
ProductSolutionsDevelopersPricingResourcesCompanyGitHub
Sign InStart building

Understand

Context layer

Why shared operational context needs its own infrastructure layer.

Product overview

Create, inspect, retrieve, use, and operate connected context.

Architecture

See the data model, query surfaces, and deployment boundaries.

Build

Ingestion and live schema

Turn evolving payloads into typed, inspectable structure.

Graph and relationships

Preserve known links and review suggested patterns.

Semantic retrieval

Combine similarity, exact filters, and connected records.

Smart Search

Generate inspectable SearchQuery from natural language.

Operate

Query and analytics

Use one query shape across records, schema, and metrics.

Deployment options

Use managed cloud, an External Database, or self-hosted infrastructure.

Security

Review privacy, controls, and deployment posture.

Explore the product →

Primary workflows

Agent context and memory

Durable state, decisions, tool output, and semantic recall.

GraphRAG

Retrieve connected evidence, not only similar chunks.

Applications

Build operational software on connected context.

Operational analytics

Analyze current values, relationships, and change.

Solution patterns

Customer intelligence

Connect customer, product, support, and event data.

Search and discovery

Power semantic, faceted, and connected discovery.

Evidence and compliance

Keep operational evidence connected and inspectable.

Blueprints

Agent systemsConnected applicationsAnalytical systemsAll blueprints
Explore all solutions and blueprints →

Documentation

Concepts, tutorials, deployment, and API guides.

Quickstart

Create a project and run your first query.

TypeScript SDK

Type-safe access for browser and Node.js applications.

Python SDK

Sync and async access for services and data workflows.

MCP server

Expose RushDB operations to MCP-compatible clients.

Agent skills

Install task guidance for memory, querying, and modelling.

Open documentation →

Guides

Evergreen explanations and implementation paths.

Comparisons

Evaluate RushDB against graph, vector, and memory tools.

Blog

Product updates and technical articles.

Architecture

Understand the data path and current boundaries.

Changelog

Follow product and platform releases.

LMPG research

Separate the property-centric implementation from research direction.

Explore resources →

Contact

Discuss product, architecture, or enterprise requirements.

Security

Security, privacy, and responsible disclosure.

Open source

Review the source, open issues, and contribute.

Contact RushDB →
rushdb

Open-source context infrastructure for agents, applications, and analytics, with connected records, live schema, semantic retrieval, and operational queries through one API.

GitHubDiscord

Product

Context layerProduct overviewArchitecturePricingSecurityDeployment

Solutions

Agent contextGraphRAGApplicationsOperational analyticsBlueprint library

Developers

DocsQuick startAPI referenceTypeScript SDKPython SDKMCP serverAgent skills

Resources

GuidesComparisonsBlogChangelogOpen sourceContactSelf-hosting

© 2026 Collect Software Inc.

PrivacyTermsCookies
Engineering11 min read21st May 2026

RushDB 2.0: Memory Infrastructure for the Agentic Era

RushDB 2.0 is a major release built for the agentic era: native semantic search, ontology-aware querying, MCP with OAuth, bring-your-own Neo4j, and prebuilt agent skills. It turns memory infrastructure into one unified layer, so developers can store structured context, traverse relationships, and search by meaning without stitching together multiple systems.

By RushDB Team
On this page
  1. 1. Native Semantic Search
  2. Creating an index
  3. Searching by meaning
  4. Semantic search + metadata filters (prefilter mode)
  5. Bring Your Own Vectors (external indexes)
  6. 2. Ontology API — Data Explains Itself
  7. 3. MCP Server + OAuth
  8. Claude Desktop setup (API key mode)
  9. What the agent gets
  10. 4. Skills — Skip the Boring Part
  11. rushdb-agent-memory
  12. rushdb-query-builder
  13. rushdb-data-modeling
  14. rushdb-faceted-search
  15. 5. SearchQuery select + groupBy
  16. 6. Bring Your Own Neo4j — Everyone
  17. 7. KU Pricing — One Metric
  18. 8. Dashboard Improvements
  19. Putting It Together: A Memory Layer in 15 Lines
  20. Getting Started
  21. What's Next

On this page

  1. 1. Native Semantic Search
  2. Creating an index
  3. Searching by meaning
  4. Semantic search + metadata filters (prefilter mode)
  5. Bring Your Own Vectors (external indexes)
  6. 2. Ontology API — Data Explains Itself
  7. 3. MCP Server + OAuth
  8. Claude Desktop setup (API key mode)
  9. What the agent gets
  10. 4. Skills — Skip the Boring Part
  11. rushdb-agent-memory
  12. rushdb-query-builder
  13. rushdb-data-modeling
  14. rushdb-faceted-search
  15. 5. SearchQuery select + groupBy
  16. 6. Bring Your Own Neo4j — Everyone
  17. 7. KU Pricing — One Metric
  18. 8. Dashboard Improvements
  19. Putting It Together: A Memory Layer in 15 Lines
  20. Getting Started
  21. What's Next

RushDB

Give your agent a memory.

Push any JSON. Get graph relationships and vector search instantly — no schema, no pipeline, no setup.

Start building free →

FAQ

Related reading

GraphRAGVector SearchRAG Architecture

Vector RAG vs GraphRAG vs Agentic RAG: Why There Is No Winner

Vector RAG, GraphRAG, and Agentic RAG preserve different context. Learn when each works, where each fails, and how to combine them in one app.

28 min readRead →
AI agentsagent memorypersistent memory

Persistent Agent Memory for OpenClaw and Hermes with RushDB

RushDB brings scoped, durable, lifecycle-aware memory to OpenClaw and Hermes Agent through native connectors and one shared event contract.

10 min read
Read →
vector searchgraph databasehybrid retrieval

Vector Search Doesn't Understand Data Structure

Embeddings rank similarity but ignore joins, cardinality, and constraints. Learn how RushDB combines semantic retrieval with explicit graph relationships and live schema discovery.

15 min readRead →

Native semantic search, Ontology API, MCP + OAuth, Bring Your Own Neo4j, Skills, and a pricing model that makes sense.


When we built the first version of RushDB, the pitch was simple: push JSON, get a graph database back. No schema design, no migration files, auto-linked nested records, a clean query API. Batteries included.

That pitch still holds. But the industry moved, and we moved with it.

The biggest shift in software development right now isn't a new framework or language. It's that applications need to remember things and reason across structured data — and the infrastructure to do that reliably, without three separate systems, barely existed.

RushDB 2.0 is the answer we kept building toward. Here's everything that shipped.


1. Native Semantic Search

The old way to add semantic search to a graph database: run a separate vector store, write an embedding pipeline, keep them synchronized, query both, merge results. Four separate concerns, none of them fun.

RushDB 2.0 has native vector support built directly into the graph. Embedding indexes are a first-class concept — you create one on any string property, and RushDB manages everything from there.

Creating an index

# Python
db.ai.indexes.create({
    "label": "DECISION",
    "propertyName": "rationale"
    # sourceType defaults to 'managed' — RushDB handles embeddings
})
Shell
# MCP tool (Claude, Cursor, VS Code)
createEmbeddingIndex: { label: "DECISION", propertyName: "rationale" }

RushDB immediately starts backfilling existing records asynchronously. Check progress:

# Python
stats = db.ai.indexes.stats(index_id)
# { "totalRecords": 4200, "indexedRecords": 3847 }

Searching by meaning

Once the index is ready:

# Python
results = db.ai.search({
    "labels": ["DECISION"],
    "propertyName": "rationale",
    "query": "why did we choose that authentication approach",
    "limit": 5
})
# Returns records ranked by __score — no exact keyword match needed

Semantic search + metadata filters (prefilter mode)

This is the most practical pattern — combine semantic ranking with structured filtering:

# Python
results = db.ai.search({
    "labels": ["DECISION"],
    "propertyName": "rationale",
    "query": "authentication approach",
    "where": {
        "status": "confirmed",
        "decidedAt": {"$gte": "2026-01-01T00:00:00Z"}
    },
    "limit": 10
})

When where is present, RushDB filters candidates first, then ranks by similarity. Exact results, semantic recall.

Bring Your Own Vectors (external indexes)

Using a different embedding model? Supply vectors yourself:

# Python
db.ai.indexes.create({
    "label": "ARTICLE",
    "propertyName": "content",
    "sourceType": "external",
    "dimensions": 768
})

# Python SDK: upsert_vectors(index_id, params)
db.ai.indexes.upsert_vectors("idx_abc", {
    "items": [
        {"recordId": "rec_001", "vector": [...]},
        {"recordId": "rec_002", "vector": [...]}
    ]
})

Self-hosted? Configure your own embedding model in RUSHDB_EMBEDDING_MODEL. The index pipeline is swappable — no vendor lock-in.


2. Ontology API — Data Explains Itself

The most consistent problem in AI integrations: agents hallucinate field names, query labels that don't exist, and filter on properties with the wrong type. The root cause is that they have no authoritative schema to work from.

The Ontology API solves this at the source.

# Python
ontology = db.ai.get_ontology()

Returns:

JSON
{
  "labels": [
    {
      "label": "DECISION",
      "count": 847,
      "properties": [
        { "id": "prop_abc", "name": "topic", "type": "string" },
        {
          "id": "prop_def",
          "name": "decidedAt",
          "type": "datetime",
          "min": "2025-01-01T00:00:00Z",
          "max": "2026-05-14T00:00:00Z"
        },
        {
          "id": "prop_ghi",
          "name": "rationale",
          "type": "string",
          "vectorIndexes": [
            {
              "id": "idx_001",
              "status": "ready",
              "sourceType": "managed",
              "similarityFunction": "cosine",
              "dimensions": 1536
            }
          ]
        }
      ]
    }
  ],
  "relationships": [{ "from": "SESSION", "to": "DECISION", "type": "HAS_DECISION" }]
}

The markdown variant (getOntologyMarkdown) is what MCP agents call at session start. It surfaces everything in one pass: labels, types, value ranges, relationship map, and a Semantic Search column that tells the agent which fields support semanticSearch. No guessing. No schema discovery round-trips.

This one API makes analytical queries more reliable, reduces hallucinations, and gives agents the context they need before they ask their first question.


3. MCP Server + OAuth

The MCP server ships with full OAuth 2.0 support — standard RS256, JWKS endpoint, per-user token scoping. Connect it to Claude Desktop, Cursor, VS Code, or ChatGPT and each user authenticates independently. Read-only tools work without auth, write tools require a token.

Claude Desktop setup (API key mode)

JSON
{
  "mcpServers": {
    "rushdb": {
      "command": "npx",
      "args": ["@rushdb/mcp-server"],
      "env": { "RUSHDB_API_KEY": "your-key" }
    }
  }
}

What the agent gets

The MCP server exposes the full RushDB toolset — 35+ tools covering every operation:

  • Discovery: getOntologyMarkdown, getOntology, findProperties, propertyValues
  • Read: findRecords, findOneRecord, getRecord, findRelationships, exportRecords
  • Write: createRecord, updateRecord, bulkCreateRecords, attachRelation
  • AI: createEmbeddingIndex, semanticSearch, getEmbeddingIndexStats, upsertEmbeddingVectors
  • Analytics: findRecords with select + groupBy

The getSearchQuerySpec tool delivers the complete query syntax into the agent's context window on demand — so it doesn't have to carry the full spec in its system prompt.


4. Skills — Skip the Boring Part

Skills are pre-written, structured knowledge files for AI coding agents. Drop them into your project alongside your agent configuration, reference them by name, and the agent already knows how to do the thing correctly.

Four skills ship with RushDB 2.0:

rushdb-agent-memory

Turns RushDB into a persistent memory layer. The skill teaches the agent the store → link → recall pattern, session management, the recommended label taxonomy (SESSION, DECISION, ENTITY, TASK, PREFERENCE), and how to traverse related memories across conversations.

rushdb-query-builder

The discovery-first workflow for safe, correct query construction. Mandatory ontology check before querying, intent classification, query spec loading for complex operations. Agents that load this skill don't hallucinate label names.

rushdb-data-modeling

LMPG schema design: label naming conventions, property types, relationship modeling, nested JSON import patterns, schema evolution without migrations.

rushdb-faceted-search

Build filter UIs that derive from live schema. Discover properties → enumerate values → map to widgets → assemble where clause as the user interacts. No hardcoded field names.

Shell
# Install
npm install @rushdb/skills

# Reference in your agent config (VS Code example)
"skills": ["rushdb-query-builder", "rushdb-agent-memory"]

5. SearchQuery select + groupBy

Analytical workloads now live entirely in the query layer. No more pulling records to count them in application code.

# Python — how many decisions per topic, last 90 days?
result = db.records.find({
    "labels": ["DECISION"],
    "where": {
        "decidedAt": {"$gte": "2026-02-14T00:00:00Z"}
    },
    "select": {
        "topic": "$record.topic",
        "count": {"fn": "count"}
    },
    "groupBy": ["$record.topic"],
    "orderBy": {"count": "desc"}
})

Sum, avg, min, max, collect, timeBucket — all available. Relationship traversal works inside the same query.


6. Bring Your Own Neo4j — Everyone

Free accounts, pro accounts, everyone. Connect your own Neo4j instance and keep full control of your data. The LMPG model sits on top of Neo4j — using your own instance means your data never leaves your infrastructure.


7. KU Pricing — One Metric

Knowledge Units. One number that reflects how much knowledge your application creates and queries. Not instance hours, not storage tiers, not separate API call pricing.

Free tier got a real upgrade: more KUs per month, zero feature restrictions. Every feature in RushDB 2.0 is available to free users.


8. Dashboard Improvements

  • Record editing in-place — click a field, edit it, done
  • Reworked graph visualization — see the actual structure of your data, not just a node cloud
  • Cleaner navigation and faster load times
  • Better separation between cloud and self-hosted feature sets

Putting It Together: A Memory Layer in 15 Lines

# Python
from rushdb import RushDB
import os

db = RushDB(os.environ["RUSHDB_API_KEY"])

# Store a session with auto-linked memories
db.records.import_json(
    label="SESSION",
    data={
        "startedAt": "2026-05-15T10:00:00Z",
        "topic": "product architecture review",
        "DECISION": [
            {"topic": "auth", "decision": "Use Clerk", "rationale": "Better Next.js integration", "status": "confirmed"}
        ],
        "ENTITY": [{"name": "Clerk", "type": "service"}]
    }
)

# Recall by meaning — no exact keyword match needed
past_decisions = db.ai.search({
    "labels": ["DECISION"],
    "propertyName": "rationale",
    "query": "how we handled login and authentication",
    "limit": 5
})

That's the full loop: store structured + relational data, search by meaning, combine with filters. No vector store, no embedding pipeline, no separate graph database.


Getting Started

Shell
# Cloud (free)
# 1. Create a project at app.rushdb.com
# 2. Copy your API key

# Install the SDK
npm install @rushdb/javascript-sdk

# Or connect via MCP
npx @rushdb/mcp-server

Full docs: docs.rushdb.com MCP quickstart: docs.rushdb.com/mcp-server/quickstart Agent setup: rushdb.com/agent-setup GitHub: github.com/rush-db/rushdb


What's Next

We're building toward a world where the data layer and the memory layer are the same thing — where agents, humans, and applications all read and write to the same graph, with the same query language, and understand each other's context.

2.0 is a big step in that direction. We'd love to hear what you build with it.