RushDB Docs

Docs

• Agents: RushDB gives agents a structured data layer, a traversable graph, and persistent memory. Choose the shortest setup that matches your agent.
• Connect RushDB: Start with the path that matches how you work. Each option gets you to a working RushDB connection first, then points to the next useful workflow.
• MCP Server: Give an AI assistant direct access to your RushDB project without writing integration code. RushDB supports hosted OAuth connections for web assistants and a local npx server for desktop and coding tools.
• SDK & REST: Use the TypeScript SDK, Python SDK, or REST API when RushDB is part of your application, service, script, or data pipeline.
• Agent Skills: Install RushDB Agent Skills to teach compatible AI assistants how to query RushDB correctly, model graph data, build faceted search, and use RushDB as persistent memory.
• Environment Variables: Complete reference for all RushDB environment variables.
• Get API Key: Register for RushDB, create a project, and generate your first API token to start building.
• Configuration: Configure environment variables, authorization, and security for your RushDB instance.
• Security: How RushDB stores data, enforces project isolation, and what to harden in production.
• Connecting a Neo4j Aura Instance (BYOC): Use your own Neo4j or Aura database as the RushDB data store — keep data in your cloud account while using the full RushDB API.
• MCP Quickstart for Real Operators: Claude, Cursor, and VS Code: Go beyond installation — learn the operator workflow for grounded, hallucination-resistant agent queries with the RushDB MCP server.
• Project Setup After Deployment: Create projects, configure per-project embedding models, invite team members, and verify SDK connectivity on a self-hosted RushDB instance.
• Infrastructure: Configure RushDB's data layer — the graph backend (Neo4j or Aura) and the relational database (PostgreSQL or SQLite).
• Neo4j & Aura: Configure RushDB's graph backend — bundled Neo4j via Docker Compose, an existing Neo4j instance, or Neo4j Aura (BYOC).
• PostgreSQL / SQLite: Configure the relational database used by RushDB for project metadata, users, and API keys.
• RushDB Platform: How the RushDB NestJS application process works — ports, startup dependencies, static serving, health check, CLI, and resource requirements.
• Docker: Run RushDB locally with Docker Compose (full stack) or a single docker run command against an existing Neo4j instance.
• From Source: Clone the RushDB repository and run the platform locally with pnpm dev — Neo4j and PostgreSQL start in Docker while the NestJS API and dashboard run as local Node.js processes.
• Helm: Deploy RushDB on Kubernetes using the official Helm chart — values reference, Neo4j wiring, ingress, and persistence.
• Local Installation: Run RushDB on your machine. Choose between Docker, running from source, or a Kubernetes Helm chart.
• AWS / GCP / Azure: Deploy RushDB on major cloud providers — AWS EC2, Google Cloud Compute Engine, or Azure Virtual Machines.
• DigitalOcean: Deploy RushDB on a DigitalOcean Droplet with Docker Compose.
• Remote Hosting: Deploy RushDB to a remote server. Choose your cloud provider or run Docker on any Linux machine.
• Prerequisites: System requirements and software dependencies before deploying RushDB to a remote server.
• Self-Hosting RushDB: Deploy RushDB on your own infrastructure with Docker Compose, connect your own Neo4j instance, and configure embedding support.
• Quick Start: The fastest path to RushDB — pick your preferred tool.
• Agent Memory Overview: RushDB is designed from the ground up as a structured memory store for AI agents. Unlike flat vector databases or document stores, RushDB gives agents three distinct memory layers — each addressing a different dimension of knowledge — and a retrieval stack that composes them at query time.
• Agent Memory Quickstart: Give any agent a persistent, graph-structured memory in under five minutes. Sessions, decisions, tasks, entities, and preferences — stored in RushDB, traversable by meaning.
• Schema Self-Awareness: RushDB is self-aware — it continuously tracks its own structure and exposes it on demand. Agents use this to operate against an unknown or evolving knowledge graph without any hardcoded schema documentation.
• Discover Your Schema: RushDB is self-aware — it continuously understands its own structure: labels, field types, value distributions, relationships, and semantic search readiness. The db.ai ontology methods expose this as either Markdown (for LLM injection) or structured JSON (for schema UIs, autocomplete, or property-ID lookups).
• Export Data: Export records as CSV. Accepts the same where, orderBy, skip, limit, and labels parameters as a search query — filtering and sorting apply before export.
• Find & Query: RushDB provides four read methods: look up by ID, find one, find unique, or run a full search query with filtering, aggregation, and relationship traversal — all through a unified SearchQuery object.
• Import Data: RushDB accepts raw data — JSON objects, nested trees, flat arrays, or CSV — and turns it into a fully typed, linked graph. No schema definitions, no migrations, no manual relationship wiring.
• Records & Queries: RushDB stores data as Records: labeled graph nodes with typed properties. You can write flat rows, import nested JSON, inspect the schema that emerges, and query records through one composable SearchQuery structure.
• Labeled Meta Property Graph: RushDB uses a Labeled Meta Property Graph model: application records remain flexible graph nodes, while their field definitions are represented as metadata nodes inside the same graph.
• Labels & Properties: RushDB is schema-free — labels and properties emerge automatically as you write records. These APIs let you inspect, enumerate, and manage your schema at runtime.
• Raw Queries: This endpoint is only available when your project is connected to your own Neo4j database. Connecting a custom Neo4j instance is available on the free tier — see the RushDB dashboard to set it up.
• Store Records: A Record is a typed key-value node with a label. Records are the fundamental unit of data in RushDB — like a document in a document store, but with seamless relationship traversal built in.
• Transactions: Group multiple write operations into an atomic unit — all succeed together or all roll back together.
• MCP Server: RushDB exposes a Model Context Protocol server for agents that need to discover, query, mutate, and traverse a project graph. Each tool publishes its input and output JSON schemas to the connected MCP client.
• All Tools: RushDB MCP exposes 37 tools. Names below use the exact lower camel case identifiers published in the MCP manifest.
• Python SDK: The official Python SDK for RushDB. Compatible with Python 3.8+.
• Record: The Record class represents a record in RushDB and provides methods for manipulating individual records, including updates, relationships, and deletions.
• Relationship Patterns: RushDB can analyze the project ontology and suggest relationships that are not materialized yet. Suggestions are reviewable: no relationship is created until you approve a pattern.
• RushDB: The RushDB class is the main entry point for interacting with RushDB from Python. It manages authentication, HTTP communication, and exposes all API namespaces.
• SearchResult: The SearchResult class is a container for search results that follows Python SDK best practices. It provides both list-like access and iteration support, along with metadata about the search operation including total count and pagination information.
• SearchQuery: SearchQuery is a dictionary type that defines the structure for querying records in RushDB. It provides a flexible way to filter, sort, paginate, and shape results. For more information on search concepts, see the search documentation.
• Transaction: A Transaction groups multiple database operations so they succeed or fail together. Obtain one via db.tx.begin(), then pass it to any write method. Call commit() to make changes permanent or rollback() to discard them.
• Advanced Indexing — BYOV: External indexes (BYOV — Bring Your Own Vectors) let you supply pre-computed embedding vectors instead of having the server compute them. Use them when you need:
• Embedding Indexes: An embedding index is a policy that tells RushDB to vectorize a specific string property for a label. Once status is ready, every record matching that label+property pair is searchable via POST /api/v1/ai/search.
• Overview: RushDB is a self-aware memory layer for agents, humans, and apps. It continuously understands its own structure — labels, fields, value distributions, relationships — and exposes that knowledge so agents can reason over real data without hallucinating schema details, and apps can retrieve semantically relevant context on demand.
• Semantic Search: POST /api/v1/ai/search
• Writing Records with Vectors: RushDB lets you attach pre-computed embedding vectors to records at write time, eliminating the need for a separate POST /api/v1/ai/indexes/:id/vectors/upsert call. Any endpoint that creates or modifies records accepts a vectors field.
• Introduction: Base URL//api.rushdb.com/api/v1
• Labels: Search Labels
• Properties: Search Properties
• Raw Queries: This endpoint is only available when your project is connected to your own Neo4j database. Connecting a custom Neo4j instance is available on the free tier — see the RushDB dashboard to set it up.
• Create Records: Create a Record
• Delete Records: Delete by ID
• Export Data: Export records as CSV. Accepts the same where / orderBy / skip / limit / labels parameters as a search query.
• Get Records: Get Record by ID
• Import Data: Import JSON
• Update Records: Partial Update
• Relationships: Attach
• Transactions: Begin Transaction
• DBRecord: DBRecord is a type representing a database record in RushDB. It combines internal system properties with schema-defined data properties.
• DBRecordInstance: DBRecordInstance is a class that wraps a DBRecord and provides methods for manipulating it. This class serves as an interface for working with individual records in the database. It allows for updating properties and managing relationships.
• DBRecordsArrayInstance: DBRecordsArrayInstance is a class that manages an array of DBRecordInstance objects. It typically represents the result of a search query that returns multiple records.
• DBRecordTarget: DBRecordTarget is a type that represents a target record for operations like set, update, attach, detach, and delete. It is commonly used when working with relationships and property updates.
• TypeScript / JavaScript SDK: The official TypeScript/JavaScript SDK for RushDB. Works in Node.js and browser environments.
• Model: The Model class represents a schema-defined entity in RushDB. It provides methods to perform CRUD operations and manage relationships between records. Models are identified by labels in the database.
• Relationship Patterns: RushDB can analyze the project ontology and suggest relationships that are not materialized yet. Suggestions are reviewable: no relationship is created until you approve a pattern.
• RelationTarget: RelationTarget is a type that represents the target(s) for relationship operations like attach and detach.
• RushDB: The RushDB class is the main entry point for interacting with the RushDB database. It manages API connections and model registration. It provides access to records, labels, and transactions.
• SearchQuery: SearchQuery is a type that defines the structure for querying records in RushDB. It provides a flexible way to filter, sort, paginate, and compute metrics using select and groupBy. The legacy aggregate clause is deprecated and should only be used for vector similarity until select supports it. For more information on search concepts, see the search documentation.
• Transaction: The Transaction class represents an active database transaction in RushDB. It provides methods for committing or rolling back the transaction and includes the unique transaction identifier.
• Bulk Relationships: Connect or disconnect many records at once by matching on property keys. Useful after importing flat data from CSV, MongoDB exports, or external APIs where related records arrive separately with reference fields.
• Connect Records: Relationships are the connections that link records together, creating a graph structure. They have a type (a string label you define) and a direction.
• Relationships: Relationships connect RushDB records into a traversable graph. They are named, directed edges between records, not foreign-key columns or application-side joins.
• Suggested Patterns: RushDB can analyze the labels, properties, and existing edges in a project and suggest relationship patterns worth making explicit. Review suggestions before applying them: analysis proposes graph structure, but approval is the step that changes relationships.
• Grouping Search Results: The groupBy option in a SearchQuery lets you pivot, summarize, and compute metrics on records instead of returning a raw list. It works together with the select clause. If no select expressions are provided, groupBy is ignored. The legacy aggregate clause is deprecated and should only be used for vector similarity until select supports it.
• Pagination and Order: SearchQuery provides flexible pagination and ordering capabilities to control the volume of returned data and the sequence in which records are presented.
• Labels: The labels property in SearchQuery allows you to filter records by their label types. Labels in RushDB are categories or classifications assigned to records that help organize and identify different types of data.
• Introduction: RushDB provides a powerful and flexible search system that allows you to efficiently query and traverse your graph data. The Search API is a cornerstone of RushDB, enabling you to find records, filter by conditions, navigate relationships, compute metrics, and format the returned data exactly as needed. The legacy aggregate clause is deprecated and should only be used for vector similarity until select supports it.
• Select Expressions: The select clause shapes the output of a SearchQuery: compute metrics, derive new metrics from other outputs, collect related records as arrays, and bucket datetime fields into calendar intervals — all in a single declarative map. The legacy aggregate clause is deprecated and should only be used for vector similarity until select supports it.
• Where: The where clause in SearchQuery is a powerful mechanism to filter records based on property values and relationships. It's one of the key elements that make RushDB queries flexible and expressive.
• Bring Your Own Vectors: External indexes let you supply pre-computed embedding vectors instead of having the server compute them. Use them when you need:
• Manage Embedding Indexes: An embedding index is a policy that tells RushDB to vectorize a specific string property for a label. Once status is ready, every record matching that label+property pair is searchable via db.ai.search().
• Semantic Search: db.ai.search() / POST /api/v1/ai/search performs semantic vector search across records that have an associated embedding index. Candidates are narrowed by label and where filters first, then ranked by cosine or euclidean similarity.
• Write Records with Vectors: RushDB lets you attach pre-computed embedding vectors to records at write time, eliminating the need for a separate bulk-upsert call. Any operation that creates or modifies records accepts a vectors parameter.
• Agent-Safe Query Planning with Ontology First: A repeatable agent pattern — ontology first, query spec second, constrained execution, and failure recovery when labels or fields are wrong.
• Using RushDB Agent Skills in OpenClaw: End-to-end guide — connect RushDB to OpenClaw, install the RushDB skills pack, and let your AI assistant query, store, and model structured data without writing a single line of code.
• Building Team Memory for Product and Support Workflows: Ingest tickets, docs, decisions, incidents, and feature requests into a connected graph so your team can retrieve context instead of isolated documents.
• Episodic Memory for Multi-Step Agents: Store goals, intermediate observations, tool outputs, and decisions as linked records so long-running agents can resume with context instead of stateless prompts.
• RushDB as a Memory Layer: Facts, Episodes, and References: Model persistent facts, episodic interactions, and linked reference material as a graph so agents and applications can retrieve and reason over connected context.
• Research Knowledge Graph: Papers, Authors, Topics, Citations: Build a scholarly graph supporting citation traversal, topical clustering, and author-centric discovery for research workflows.
• Semantic Search in 5 Minutes: Create embedding indexes, wait for backfill, and run your first semantic search query in TypeScript, Python, or REST.
• Bring Your Own Vectors (BYOV) — External Embeddings: Use your own embedding model to generate vectors and store them in RushDB, then search with queryVector instead of query text.
• BYOV in Practice: When and Why to Bring Your Own Vectors: A case study showing exactly when BYOV makes sense, when it doesn't, and a complete walkthrough of a real scenario where you already have vectors from your own pipeline.
• Explainable Results: Pair raw search results with related evidence, summary metrics, and traversal paths so users and agents can understand why a result was returned.
• GraphRAG — Graph-Enriched Retrieval Augmented Generation: Retrieve chunks semantically, then traverse the knowledge graph to assemble author, topic, and source provenance as richer LLM context.
• Hybrid Retrieval: Filters Plus Semantic Search: Combine structured where-clause filtering with vector semantic search to narrow candidates by business constraints, then rank by relevance.
• RAG Evaluation: Measure Precision@k and Recall@k for your retrieval pipeline, detect score drift after model updates, and add a CI regression gate that fails on quality drops.
• Multi-Source RAG: Ingest PDFs, web pages, and database records as distinct labels, then search across all sources in a single vector query with source-aware citations.
• RAG Pipeline in Minutes: Chunk Markdown files, store them in RushDB, and build a retrieval-augmented generation pipeline in TypeScript, Python, or REST.
• RAG Reranking: Improve retrieval precision with two-stage search — over-fetch candidates with vector similarity, then rerank with LLM scoring or Reciprocal Rank Fusion before sending to the LLM.
• Semantic Search for Multi-Tenant Products: Build tenant-safe semantic retrieval using RushDB's project-scoped prefilter and exact cosine similarity ranking — without global index assumptions.
• Choosing Relationship Types That Age Well: When to use generic nesting-driven edges versus explicit typed relationships, and how that choice affects readability, search, and analytics downstream.
• Customer 360 as a Connected Graph: Model users, accounts, subscriptions, invoices, touchpoints, and support interactions as a connected graph so customer context becomes retrievable instead of siloed.
• End-to-End Data Lineage: From Source to Answer: Model imported records, transformation steps, derived summaries, and final outputs so every answer can be traced back to its upstream source.
• Modeling Hierarchies, Networks, and Feedback Loops: Three common graph shapes — trees, many-to-many networks, and cyclic systems — with guidance on how to query each without flattening away meaning.
• Temporal Graphs: Modeling State and Event Time Together: Represent durable entities alongside time-stamped events so you can answer both current-state and historical questions without losing lineage.
• Thinking in Graphs: From Tables to Traversals: Map the same product, customer, and order dataset from relational and document mental models into RushDB's graph model, then translate common business questions into multi-hop queries.
• Versioning Records Without Losing Queryability: Compare in-place mutation, append-only versions, and hybrid versioning approaches — and how to query latest state while preserving historical analysis.
• Tutorials: Step-by-step guides to build real things with RushDB — from deployment to AI-powered search and RAG pipelines.
• Discovery Queries: Exploring an Unknown Schema: A practical workflow for exploring a RushDB project you did not design — using ontology tools, label listing, and progressive query refinement before building reliable retrieval.
• Query Optimization: Shape SearchQuery, traversal breadth, aggregation strategy, and batch patterns to reduce compute cost and improve throughput.
• Reusable SearchQuery: Learn the canonical SearchQuery shape reused across records, properties, labels, relationships, and values
• Search UX Patterns: Combine structured filters, semantic ranking, and contextual fields to build explainable, user-facing search experiences on top of RushDB.
• SearchQuery Deep Dive: Advanced Patterns: Build confidence with advanced SearchQuery patterns through realistic RushDB examples
• Testing SearchQuery Across TypeScript, Python, and REST: Write parity-driven tests that prove one query intent behaves identically across every RushDB surface.
• Audit Trails with Immutable Events and Derived State: Log business events as immutable records separate from current state so teams can reconstruct what happened, not just what is true now.
• BYOC vs Managed vs Self-Hosted: Compare RushDB's three deployment models — Managed, BYOC (Bring Your Own Cloud), and Self-Hosted — with a feature matrix, decision guide, and step-by-step migration path.
• Compliance and Retention Patterns: Implement expiration, archival, and field-level redaction for GDPR, CCPA, and other data lifecycle requirements in RushDB without breaking graph structure.
• Incident Response Graphs: Model operational incidents as graph structures to answer root cause, blast radius, and resolution timeline questions in a single query.
• Is RushDB Right for My Problem? A Practical Decision Guide: A scenario-driven catalog showing seven problems RushDB is designed for, where it outperforms fragmented stacks, and where it isn't the right fit.
• Supply Chain Traceability and Recall Analysis: Model suppliers, batches, products, shipments, and incidents so teams can answer upstream-impact and downstream-blast-radius questions for recalls.
• Event-Driven Ingestion from Webhooks and Queues: Handle partial, repeated, and out-of-order events from webhooks or message queues without corrupting connected graph state.
• Building a Graph-Backed API Layer: Expose RushDB through an application API with query translation, safe filtering, and response shaping patterns for production use.
• Importing data from external sources: Learn how to import your data to RushDB
• Importing from MongoDB: A step-by-step guide to migrating MongoDB collections to RushDB — nested documents, embedded arrays, upsert, and change streams
• Webhook Ingestion from Third-Party Tools (Clay, Supabase, Superglue): A beginner-friendly guide to send JSON or CSV from no-code and data platforms into RushDB using custom HTTP requests.
• Billing Model: How RushDB Cloud bills for Knowledge Units, applies plan limits, and treats self-hosted deployments.
• RushDB Cloud: Understand RushDB Cloud billing, project isolation, licensing, third-party services, and self-hosted alternatives.
• Knowledge Units (KU): Understand the RushDB Cloud usage metric for ingestion, graph structure, compute-intensive operations, and storage footprint.
• Licensing & Third-Party Services: RushDB software licenses and the storage, model, identity, email, CAPTCHA, and billing services that may participate in a deployment.
• Multitenancy & Project Isolation: How RushDB scopes graph data, metadata, API tokens, and BYOC connections with projectId.