RushDB 2.0: Memory Infrastructure for the Agentic Era
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
RushDB immediately starts backfilling existing records asynchronously. Check progress:
Searching by meaning
Once the index is ready:
Semantic search + metadata filters (prefilter mode)
This is the most practical pattern — combine semantic ranking with structured filtering:
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:
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.
Returns:
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)
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:
findRecordswithselect+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.
5. SearchQuery select + groupBy
Analytical workloads now live entirely in the query layer. No more pulling records to count them in application code.
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
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
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.
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
More Posts
Knowledge Graphs: Semantic Reasoning Meets Graph Architecture
Labeled Property Graphs: A Comprehensive Guide to Enhanced Graph Data Modeling
Labeled Property Graphs (LPGs) represent an evolution of traditional property graphs, introducing explicit type labels for nodes and relationships. This enhancement not only improves schema clarity but also boosts query performance, making LPGs a preferred choice for complex data modeling scenarios. In this article, we explore the advantages, challenges, and practical applications of LPGs.
RDF: A Comprehensive Guide to Semantic Web Data Modeling
Resource Description Framework (RDF) represents a fundamental paradigm shift in how we model and represent knowledge on the web. As the cornerstone of the Semantic Web, RDF provides a standardized method for describing resources and their relationships in a way that is both machine-readable and semantically rich. Unlike traditional data models that focus on storage and retrieval efficiency, RDF prioritizes meaning, interoperability, and automated reasoning.