RushDB vs Neo4j: a higher-level API on graph storage.

Side by side

The same task in both: store a customer with orders, search orders by meaning.

Both snippets create a customer connected to two orders and make order summaries semantically searchable. The difference is who does the modeling and embedding work.

// Write nodes and relationships by hand
CREATE (c:Customer {customerId: 'cust-1', name: 'Acme'})
CREATE (o1:Order {orderId: 'ord-1', summary: 'Annual plan upgrade'})
CREATE (o2:Order {orderId: 'ord-2', summary: 'Added 40 seats'})
CREATE (c)-[:PLACED]->(o1), (c)-[:PLACED]->(o2);

// Semantic search: create a vector index...
CREATE VECTOR INDEX order_summaries
FOR (o:Order) ON o.embedding
OPTIONS {indexConfig: {
  `vector.dimensions`: 1536,
  `vector.similarity_function`: 'cosine'
}};

// ...then compute embeddings with your own provider key,
// write them to o.embedding, and query with
// db.index.vector.queryNodes('order_summaries', 5, $vector)

import RushDB from '@rushdb/javascript-sdk'

const db = new RushDB('RUSHDB_API_KEY')

await db.ai.indexes.create({ label: 'ORDER', propertyName: 'summary' })

await db.records.importJson({
  label: 'CUSTOMER',
  data: {
    customerId: 'cust-1',
    name: 'Acme',
    ORDER: [
      { orderId: 'ord-1', summary: 'Annual plan upgrade' },
      { orderId: 'ord-2', summary: 'Added 40 seats' },
    ],
  },
})

const recall = await db.ai.search({
  labels: ['ORDER'],
  propertyName: 'summary',
  query: 'plan changes for Acme',
})

Switching

You don’t migrate off Neo4j. You add a layer on it.

This is the unusual part of this comparison: with BYOC, RushDB is not a rip-and-replace decision. Your graph data stays in the Neo4j or Aura instance you already operate — RushDB adds the JSON-in API, managed embeddings, live schema, and MCP tools on top, while existing Cypher applications keep working against the same instance.

Who this is for

Pick the right tool for the job.

If your team already writes Cypher, models schema by hand, and wants direct access to the full graph data science and GraphAcademy ecosystem, Neo4j alone is a reasonable choice. If you want to push JSON in without modeling schema first, get managed embeddings and a live schema an agent can inspect, RushDB removes that layer of hand-built plumbing.

Comparison table

Query interface, schema, and vector search

RushDB and Neo4j overlap most on the storage layer, not the API. Rows marked with a source are Neo4j’s own documented facts, checked on the date shown; RushDB rows are verified against RushDB’s own docs referenced elsewhere on this site.

Neo4j facts sourced from neo4j.com, Neo4j’s Cypher manual, and GraphAcademy as of the dates shown above. The Cypher snippet follows Neo4j’s documented vector-index syntax. RushDB facts are drawn from RushDB’s own docs and feature pages linked throughout this site. Report a stale claim to hi@rushdb.com.

Implementation example

Store and recall agent memory without writing Cypher

This is the same store-then-recall path used across RushDB’s docs: create an index, write a record, search by meaning within a scoped filter.

from rushdb import RushDB

db = RushDB("RUSHDB_API_KEY")

db.ai.indexes.create({
    "label": "MEMORY",
    "propertyName": "output",
})

db.records.create(
    label="MEMORY",
    data={
        "agent_id": "agent-42",
        "kind": "decision",
        "output": "Keep the free plan, but increase Pro onboarding limits after launch feedback.",
        "status": "approved",
    },
)

recall = db.ai.search({
    "labels": ["MEMORY"],
    "propertyName": "output",
    "query": "What did we decide about Pro onboarding?",
    "where": {"agent_id": "agent-42", "status": "approved"},
    "limit": 5,
})

print(recall.data)

Questions developers ask.

Related

Go deeper on the workflow.