RushDB 3.0: a standalone Rust database for AI

RushDB 3.0 is the first release of RushDB as its own database engine: one Apache-2.0 Rust binary with its own write-ahead log, ordered store and MVCC snapshots. You write JSON; nested objects become linked records, and every commit updates an exact catalog of labels, properties, types, values and relationships. Query it with native JSON queries, SQL over the PostgreSQL wire, Gremlin, Mongo-style documents or SQL/PGQ, plus vector, BM25 and hybrid search. openCypher and ISO GQL are release candidates.

Highlights

• 3.0 runs as one process owning one data directory, with no external services. 2.x was a platform on Neo4j plus a SQL metadata store.
• The whole engine is Apache-2.0; the 2.x platform core was Elastic License 2.0.
• Counts, value dictionaries and relationship shapes are kept exact at every snapshot and read without scanning records.
• Seven query surfaces read one copy of the data, each with its maturity stated in the table below.
• Linux and macOS installs come as a signed installer, a multi-arch container image, Homebrew, a Helm chart and Cargo.

What is RushDB 3.0?

RushDB 3.0 is a single-process property-graph database for AI applications, written in Rust and released under Apache-2.0. You write JSON, it stores linked records with an exact catalog, and every client protocol (HTTP, PostgreSQL wire, gRPC, Bolt) is a thin transport around one versioned protocol, /protocol/v1 (architecture overview).

Data is stored in the Labeled Meta-Property Graph (LMPG) layout: each property value of each record or relationship is its own ordered key. Writes go to a segmented WAL first and are then applied to an embedded redb store. Reads run on pinned MVCC snapshots, so readers never block writers.

The engine stores and searches vectors you supply. It does not generate embeddings, host a dashboard or manage users. Those are RushDB Cloud features, and Cloud runs the same engine.

How do you install RushDB 3.0?

Install RushDB 3.0 with the signed install script on Linux or macOS, then run rushdb up to start a durable local node on port 3000. A container image, Homebrew, a Helm chart and Cargo are the other channels. There is no native Windows build.

On Linux (x86-64 or arm64, glibc 2.28+) or macOS 11+:

curl -fsSL https://raw.githubusercontent.com/rush-db/rushdb/main/install.sh | sh
rushdb up

The installer checks the SHA-256 checksum, and the Sigstore signature if cosign is present. rushdb up starts a durable node on http://127.0.0.1:3000 (data in ./.rushdb, token local-token). Check it:

rushdb health

{"status":"ok","engine":"rushdb-lmpg","protocolVersion":1,"queryLanguages":["gremlin","mongo","searchQuery","sql","sqlPgq"]}

No native Windows build; use WSL 2 or Docker. The installation guide covers tokens, data directories and the release archives.

The current release is 3.0.8 (2026-11-10). The patch releases since 3.0.0 are performance work and fixes; the changelog lists each one, including the two behaviour changes in 3.0.7 (multi-hop $relation paths are trails, and filtered vector search routes on the number of matching records).

Which query languages and protocols ship, and how mature are they?

Five query languages are stable in RushDB 3.0: the native SearchQuery document, SQL, Gremlin, SQL/PGQ and Mongo-style documents. openCypher and ISO GQL are opt-in release candidates. HTTP and the PostgreSQL wire are on by default; Bolt and gRPC are opt-in transports.

For the query languages, the status is what the server itself reports through describe.queryLanguages.

On the openCypher TCK 2024.2, 1,385 of the 2,431 scenarios in RushDB's profile pass (57%). The other 1,046 fail on known defects in Grafeo, the graph planner RushDB embeds. Another 1,466 of the suite's 3,897 scenarios test features outside the profile (temporal types, single-label checks, procedures). The query languages page lists what each language supports.

The same records answer every surface. After the quickstart writes Person records, psql sees the label as a table, with the token as the password.

PGPASSWORD="$RUSHDB_TOKEN" psql "host=127.0.0.1 port=5432 user=rushdb dbname=rushdb sslmode=disable"

SELECT name, born FROM Person ORDER BY born;

What does the schema catalog do in 3.0?

The schema catalog describes each tenant exactly: labels with record counts, properties with types and counts, stored values, and relationship shapes. It is written in the same commit as the data, so a person or an agent can read what exists without scanning records.

One request, sent with the quickstart's rdb curl helper, describes a tenant without reading records.

rdb '{"protocolVersion":1,"operation":{"kind":"describe","describe":{
  "kind":"schema","query":{},"detail":"catalog"}}}'

The answer lists labels with record counts, properties with type and recordsCount, and relationship shapes as (sourceLabel, type, targetLabel) with counts (schema catalog docs). Add a predicate and every count narrows to the matching records, which is how faceted search is built.

On the made-up data of the schema introspection example, propertyValues returns stored ORDER.status values with counts.

{"protocolVersion":1,"operation":{"kind":"query","query":{"kind":"propertyValues",
  "property":"status","mode":"topK","limit":10,"query":{"labels":["ORDER"]}}}}

{"values":["paid","refunded_full","pending","refunded_partial"],"counts":[10,4,2,2]}

No refunded value exists, and an agent sees that before it queries.

3.0 adds these catalog reads:

• propertyValues search: contains, prefix, exact or similar, answered from the value dictionaries (searching values). Year-first dates match other layouts (1993/11/12 finds 19931112); domainOnMiss lists a small property's values when nothing matches.
• query.searchValues searches every property at once (searching every property).
• describe.names suggests labels and properties spelled like a given name, ignoring case, separators and plurals (find a name). SQL "unknown table" errors carry the same suggestions (Did you mean 'Patient'?).
• describe.schemaSummary returns every label with its properties, distinct counts, ranges and few values in one read (a compact summary).
• describe.valueOverlap compares property pairs over the exact value dictionaries. It returns evidence for join suggestions; a model or a person decides which pairs are references (value overlap).

Under an enforced data-access policy, catalog reads and SQL SELECT see only allowed labels, visible properties and allowed relationship types, and minCount withholds small groups. Paths that cannot apply a policy (Cypher, GQL, Gremlin, SQL/PGQ, Mongo, text search, explain, backup) fail closed with unauthorized.

The catalog shows which fields and values exist. Deciding what "active customer" means at your company is still up to you or your model.

What about durability, transactions and operations?

In RushDB 3.0 a commit is durable once its write-ahead log record is fsynced, which is the default, and interactive transactions run under snapshot isolation. Backups, restore and read replicas ship in the same binary.

• Concurrent commits share one fsync. Why writes go through one writer, and what that costs, is the subject of Single writer by design .
• Snapshot isolation is equivalent to PostgreSQL REPEATABLE READ. First committer wins, there is no lock manager, write skew is permitted and a transaction lives at most 60 s.
• Online base backups, point-in-time restore, and asynchronous streaming replication to read-only followers. Promotion is manual.
• Optional multitenancy: each tenant is one contiguous key range under a 5-byte prefix, so a scan cannot cross tenants.
• Per-request bounds (context.deadlineMs, context.queryMemoryMaxBytes, and statement_timeout/work_mem over pgwire) can tighten the server's limits, never loosen them.

What do the measurements say?

On one laptop-class node, RushDB 3.0 bulk-ingested 12,600 records per second and served indexed filtered reads at a p50 of 2.9 ms over 200K records (capacity planning). In our capacity runs, reads that visit many candidates slow sharply by 30M records, the largest size measured so far.

All rows: one rushdb serve node, i9-12900H (20 threads), LUKS NVMe, Linux, warm page cache, 10-field records, measured 2026-10-10 to 2026-10-20 on storage format 5; 3.0 writes format 6. The docs page lists the 200K and 1M rows; the 30M row comes from our own capacity runs on the same setup, on pre-release builds before 3.0.1 (which removed a cost that grew with tenant size from indexed filters) and not re-measured since.

The last row is the current limit: reads that visit every candidate grow 5–20× for 3× the records, and the engine is not yet qualified past 30M records per node.

What is not in 3.0 yet?

RushDB 3.0 has six known gaps. The largest for production use are Raft and automatic failover, which are not shipped.

• Full openCypher and ISO GQL conformance (both release candidates).
• Raft and storage sharding: preview behind experimental flags, not for production. Raft runs in one process with in-memory state.
• Automatic failover. Replication is asynchronous with manual promotion.
• Multi-statement SQL transactions: BEGIN fails with SQLSTATE 0A000.
• Composite or relationship-property indexes, and ANN for metrics other than cosine.
• Embedding generation in the self-hosted engine.

How do you upgrade from 2.x?

RushDB 3.0 replaces the 2.x platform, a NestJS service on Neo4j, and does not read a 2.x data directory or accept 2.x REST requests. Cloud users upgrade the SDKs; self-hosted users move their data. The RushDB 3.0 vs 2.x upgrade guide has the comparison table and the steps, and Inside RushDB 3 explains the storage. For why we left Neo4j at all, read Time to move on: why RushDB took the hard path off Neo4j .

Install the latest SDK releases with npm install @rushdb/javascript-sdk@latest and pip install -U rushdb.

FAQ

Is RushDB 3.0 open source?

Yes. The whole engine workspace is Apache-2.0, including the storage, query planner and every protocol adapter. RushDB Cloud is a managed service that runs the same engine and adds managed embeddings, natural-language search, relationship suggestions, hosted MCP with OAuth and team access. Those Cloud features are not part of the open-source binary.

Does RushDB 3.0 support Cypher?

Yes, as a release candidate. Start the server with --languages sql,cypher (the flag replaces the default set), and add --bolt-port to use the Neo4j drivers over Bolt 5.0. About 57% of the TCK scenarios in RushDB's profile pass today, so check the query languages page before porting a large Cypher codebase. SQL, Gremlin and the native query document are the stable surfaces.

Which Neo4j drivers work with RushDB 3.0?

The official Python neo4j 6.4 and JavaScript neo4j-driver 6.2 drivers were run against RushDB's Bolt 5.0 transport by hand on 2026-10-15; there is no automated driver suite yet. Since 3.0.6 a driver's session database selects the tenant and neo4j:// routing works; since 3.0.4 Bolt speaks TLS. Cypher itself is still a release candidate.

Sources

• RushDB engine architecture overview
• Installation
• Query languages and status
• Schema catalog
• Capacity planning and measured envelope
• Migrate from RushDB 2.x
• RushDB on GitHub
• redb
• Grafeo
• Apache DataFusion