# RushDB 3.0: a standalone Rust database for AI

> RushDB 3.0 is its own engine: one Apache-2.0 Rust binary with an exact schema catalog, SQL, Gremlin, Mongo-style queries, vector and BM25 search.

Canonical URL: https://rushdb.com/blog/rushdb-3-0-release-notes

Updated: 2026-11-11T20:43:59.486Z
Author: RushDB
Category: Release Notes

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](https://docs.rushdb.com/engine/architecture/overview)).

```mermaid
flowchart LR
  HTTP["HTTP :3000"] --> P["protocol v1"]
  PG["PostgreSQL wire :5432"] --> P
  GRPC["gRPC, opt-in"] --> P
  BOLT["Bolt, opt-in"] --> P
  P --> Q["SearchQuery, SQL, Gremlin, Mongo, SQL/PGQ, Cypher RC, GQL RC"]
  Q -->|"read on MVCC snapshot"| R["redb store: LMPG keys and catalog"]
  P -->|"commit"| W["Segmented WAL"]
  W -->|"apply"| R
```

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](https://github.com/cberner/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](https://rushdb.com/pricing) 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+:

```bash
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:

```bash
rushdb health
```

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

| Channel | Command or location |
|---|---|
| Install script | `curl -fsSL https://raw.githubusercontent.com/rush-db/rushdb/main/install.sh \| sh` (`sh -s -- --version v3.0.8` pins a release) |
| Container | `rushdb/rushdb`, also `ghcr.io/rush-db/rushdb`, linux/amd64 and linux/arm64, signed, with SBOM and provenance |
| Homebrew | `brew install rush-db/tap/rushdb`, optional `brew services start rushdb` |
| Kubernetes | Helm chart `oci://ghcr.io/rush-db/charts/rushdb` (single-node StatefulSet) |
| Cargo | `cargo binstall rushdb-server`, or `cargo install rushdb-server --locked` (needs a C++ compiler) |
| Templates | Docker Compose (plain or behind Caddy with TLS), cloud-init, systemd, Fly.io, Render, Coolify, Dokploy |

No native Windows build; use WSL 2 or Docker. The [installation guide](https://docs.rushdb.com/engine/getting-started/installation) 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](https://github.com/rush-db/rushdb/blob/main/CHANGELOG.md) 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`.

| Surface | Default | Status in 3.0 |
|---|---|---|
| Native protocol over HTTP (`POST /protocol/v1/execute`) | on, `127.0.0.1:3000` | Stable |
| Native query document (SearchQuery) | on | Stable, read/write |
| SQL (Apache DataFusion) over HTTP and PostgreSQL wire | on, `127.0.0.1:5432` | Stable. Reads and single-statement writes in autocommit; checked with psql, node-postgres, psycopg and tokio-postgres, not every client or ORM; TLS since 3.0.4 |
| Gremlin text traversals | on | Stable; no GraphBinary or Gremlin Server endpoint |
| SQL/PGQ `GRAPH_TABLE` | on | Stable, read-only |
| Mongo-style documents | on | Stable; `$lookup`, `$text`, `$geoNear` and full `$unwind` return explicit errors for now |
| openCypher | opt-in (`cypher`) | Release candidate |
| ISO GQL (ISO/IEC 39075, not GraphQL) | opt-in (`gql`) | Release candidate |
| Bolt 5.0 | opt-in (`--bolt-port` with `cypher`) | Release candidate, as openCypher; TLS (`bolt+s://`) with `--tls-cert`/`--tls-key` since 3.0.4 |
| gRPC `rushdb.v1.Database/Execute` | opt-in (`--grpc-port`) | Carries every operation; TLS with `--tls-cert`/`--tls-key` (since 3.0.4) |

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](https://github.com/GrafeoDB/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](https://docs.rushdb.com/engine/languages) lists what each language supports.

The same records answer every surface. After the [quickstart](https://docs.rushdb.com/engine/getting-started/quickstart) writes `Person` records, `psql` sees the label as a table, with the token as the password.

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

```sql
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.

```bash
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](https://docs.rushdb.com/engine/data-model/schema-catalog)). 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](https://github.com/rush-db/examples/tree/main/schema-introspection-loop), `propertyValues` returns stored `ORDER.status` values with counts.

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

```json
{"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](https://docs.rushdb.com/engine/query/facets#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](https://docs.rushdb.com/engine/query/facets#searching-every-property)).
- `describe.names` suggests labels and properties spelled like a given name, ignoring case, separators and plurals ([find a name](https://docs.rushdb.com/engine/data-model/schema-catalog#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](https://docs.rushdb.com/engine/data-model/schema-catalog#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](https://docs.rushdb.com/engine/data-model/schema-catalog#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](https://docs.rushdb.com/engine/operations/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.

| Workload | Result |
|---|---|
| Bulk ingest, 200K records, 8 writers, 500-doc batches | 12,600 records/s |
| Filtered read (`status ∧ city`), 200K records, 32 clients | p50 2.9 ms with ordered indexes; p50 17 ms without |
| Single-record commits, one tenant | ~1,015/s with 32 writers, 114/s with one (one publisher serializes writes) |
| `/ready` after `kill -9`, 1M records | 0.07 s; nothing is rebuilt at boot |
| Filtered page reads, 30M records, 32 clients | p50 15.0 s, p99 23.2 s |

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](https://rushdb.com/blog/rushdb-3-vs-2-upgrade-guide)  has the comparison table and the steps, and [Inside RushDB 3](https://rushdb.com/blog/lmpg-rust-architecture-deep-dive)  explains the storage. For why we left Neo4j at all, read [Time to move on: why RushDB took the hard path off Neo4j](https://rushdb.com/blog/time-to-move-on-from-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](https://docs.rushdb.com/engine/languages) 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](https://docs.rushdb.com/engine/architecture/overview)
- [Installation](https://docs.rushdb.com/engine/getting-started/installation)
- [Query languages and status](https://docs.rushdb.com/engine/languages)
- [Schema catalog](https://docs.rushdb.com/engine/data-model/schema-catalog)
- [Capacity planning and measured envelope](https://docs.rushdb.com/engine/operations/capacity-planning)
- [Migrate from RushDB 2.x](https://docs.rushdb.com/migration/from-2x)
- [RushDB on GitHub](https://github.com/rush-db/rushdb)
- [redb](https://github.com/cberner/redb)
- [Grafeo](https://github.com/GrafeoDB/grafeo)
- [Apache DataFusion](https://github.com/apache/datafusion)