Release/2.0

.changeset/big-singers-buy.md

@@ -0,0 +1,10 @@
+---
+'@rushdb/javascript-sdk': minor
+'@rushdb/mcp-server': minor
+'rushdb-dashboard': minor
+'rushdb-core': minor
+'rushdb-website': minor
+'rushdb-docs': minor
+---
+
+Decoupling billing from a platform

.changeset/cold-pumpkins-move.md

@@ -0,0 +1,10 @@
+---
+'@rushdb/javascript-sdk': minor
+'@rushdb/mcp-server': minor
+'rushdb-dashboard': minor
+'rushdb-core': minor
+'rushdb-website': minor
+'rushdb-docs': minor
+---
+
+Add native vector support and docs update

.changeset/old-horses-explain.md

@@ -0,0 +1,10 @@
+---
+'@rushdb/javascript-sdk': minor
+'@rushdb/mcp-server': minor
+'rushdb-dashboard': minor
+'rushdb-core': minor
+'rushdb-website': minor
+'rushdb-docs': minor
+---
+
+Refactor dashboard

.changeset/plenty-flies-scream.md

@@ -0,0 +1,10 @@
+---
+'@rushdb/javascript-sdk': minor
+'@rushdb/mcp-server': minor
+'rushdb-dashboard': minor
+'rushdb-core': minor
+'rushdb-website': minor
+'rushdb-docs': minor
+---
+
+Add tutorials and BYOV feature

.changeset/poor-starfishes-deliver.md

@@ -0,0 +1,10 @@
+---
+'@rushdb/javascript-sdk': minor
+'@rushdb/mcp-server': minor
+'rushdb-dashboard': minor
+'rushdb-core': minor
+'rushdb-website': minor
+'rushdb-docs': minor
+---
+
+Improve separation between os and cloud versions

.changeset/rich-mails-care.md

@@ -0,0 +1,10 @@
+---
+'@rushdb/javascript-sdk': minor
+'@rushdb/mcp-server': minor
+'rushdb-dashboard': minor
+'rushdb-core': minor
+'rushdb-website': minor
+'rushdb-docs': minor
+---
+
+Add oauth and mcp improvements

.changeset/sweet-candles-tease.md

@@ -0,0 +1,10 @@
+---
+'@rushdb/javascript-sdk': minor
+'@rushdb/mcp-server': minor
+'rushdb-dashboard': minor
+'rushdb-core': minor
+'rushdb-website': minor
+'rushdb-docs': minor
+---
+
+Update docs portal

README.md

@@ -4,10 +4,9 @@
 
 # RushDB
 
-### Developer‑first property‑centric graph store
+### Turn Any Data into Intelligence
 
-RushDB lets you push raw JSON/CSV, auto-normalize it into a labeled meta property graph, and query records, schema, relationships, values, vectors and aggregations through one JSON search interface. No upfront schema design, no new query language to learn.
-RushDB transforms how you work with graph data — no schema required, no complex queries, just push your data and go.
+Push any JSON — records, events, AI outputs, configs. RushDB structures it, connects it, and makes it queryable instantly. No upfront schema design, no new query language to learn.
 
 [![GitHub Stars](https://img.shields.io/github/stars/rush-db/rushdb?style=social)](https://github.com/rush-db/rushdb)
 [![Follow on X (Twitter)](https://img.shields.io/twitter/follow/rushdb?style=social)](https://x.com/RushDatabase)
@@ -99,7 +98,7 @@ For deeper architectural exposition see the blog article on [LMPG](https://rushd
 
 ### 1. Get an API Key (Cloud) or Run Locally
 RushDB Cloud: create a project at https://app.rushdb.com → copy API key.
-Self-host (requires Neo4j 5.25.1+ with APOC & GDS):
+Self-host (requires Neo4j 2026.01.4+ with compatible APOC & GDS plugins):
 ```bash
 docker run -p 3000:3000 \
   --name rushdb \
@@ -212,9 +211,9 @@ Benefits:
 ## 🛠️ Self-Hosting
 
 ### Requirements
-- Neo4j 5.25.1+
-- APOC plugin
-- Graph Data Science plugin (for vector similarity & advanced aggregates)
+- Neo4j 2026.01.4+
+- APOC Core plugin (compatible with Neo4j 2026.01.4+)
+- Graph Data Science plugin (compatible with Neo4j 2026.01.4+, for vector similarity & advanced aggregates)
 
 ### Minimal Docker Compose
 ```yaml
@@ -266,7 +265,7 @@ services:
       - NEO4J_USERNAME=neo4j
       - NEO4J_PASSWORD=password
   neo4j:
-    image: neo4j:5.25.1
+    image: neo4j:2026.01.4
     healthcheck:
       test: [ "CMD-SHELL", "wget --no-verbose --tries=1 --spider localhost:7474 || exit 1" ]
       interval: 5s
@@ -278,7 +277,11 @@ services:
     environment:
       - NEO4J_ACCEPT_LICENSE_AGREEMENT=yes
       - NEO4J_AUTH=neo4j/password
-      - NEO4J_PLUGINS=["apoc", "graph-data-science"]
+      # Optional: auto-download plugins from the internet
+      # - NEO4J_PLUGINS=["apoc", "graph-data-science"]
+    volumes:
+      # Optional: mount local plugin jars (required for Neo4j 2026.x where auto-download may not work)
+      - ./neo4j-plugins:/var/lib/neo4j/plugins
 ```
 </details>
 

docs/docs/concepts/agent-memory-model.md

@@ -0,0 +1,98 @@
+---
+sidebar_position: 2
+---
+
+# Agent Memory Model
+
+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.
+
+## The Three Memory Layers
+
+| Layer | What it stores | RushDB primitive |
+|---|---|---|
+| **Episodic** | Individual facts, events, entities, and their connections | Records + Relationships |
+| **Semantic** | Meaning encoded as dense vectors (embeddings) | Vector Properties + AI Indexes |
+| **Structural** | Schema: what labels exist, what properties they carry, how they connect | Ontology API |
+
+### Episodic Memory — Records and Relationships
+
+Every discrete piece of knowledge is a **Record**: a typed key-value object carrying a label, properties, and a system-generated ID. Records connect to one another via **Relationships**, forming a traversable knowledge graph. An agent can store anything from a conversation turn to a product entity as a record, then retrieve it by property values, label, or graph traversal.
+
+→ See [Records](./records.md) and [Relationships](./relationships.md)
+
+### Semantic Memory — Vector Properties
+
+A subset of record properties carry dense vector representations (embeddings). Because all properties in RushDB are first-class graph nodes shared across every record with the same `(name, type)`, a vector-indexed property is simultaneously a semantic index over every record it connects to. Embeddings can be supplied by the application (Bring Your Own Vector) or generated automatically by RushDB.
+
+→ See [Properties — Vector Properties and Semantic Indexing](./properties.md#vector-properties-and-semantic-indexing)
+
+### Structural Memory — Ontology
+
+The **Ontology API** returns a live snapshot of the graph's schema: all labels, all properties per label with types and value ranges, and the full relationship map. An agent calls this once per session to bootstrap awareness of what is in the database — no hardcoded schema, no external documentation required.
+
+→ See [Ontology & Schema Discovery](./ontology-schema-discovery.md)
+
+---
+
+## The Retrieval Stack
+
+A well-designed agent retrieval pipeline uses all three layers in sequence:
+
+```mermaid
+flowchart TD
+    A([Agent]) --> B["1. Ontology discovery\nPOST /ai/ontology/md"]
+    B --> C["2. Faceted filter\nSearchQuery where clause"]
+    C --> D["3. Semantic re-rank\nvector.similarity on filtered candidates"]
+    D --> E["4. Structured results\nrecords with scores"]
+    E --> F([Agent response])
+
+    style A fill:#f5f5f5,stroke:#9e9e9e
+    style B fill:#e3f2fd,stroke:#1976d2
+    style C fill:#e8f5e9,stroke:#388e3c
+    style D fill:#fff8e1,stroke:#f57c00
+    style E fill:#f3e5f5,stroke:#7b1fa2
+    style F fill:#f5f5f5,stroke:#9e9e9e
+```
+
+**Step 1 — Discover the schema.** Before constructing any query, the agent calls the ontology endpoint to learn what labels, properties, and relationships exist. This prevents hallucinated field names and enables dynamic query construction.
+
+**Step 2 — Filter structurally.** The `where` clause narrows the candidate set by exact or range conditions on scalar properties. This is fast (index-backed) and deterministic. It is the right tool when the agent knows what it is looking for.
+
+**Step 3 — Re-rank semantically.** After structural filtering, a `vector.similarity` aggregation scores each candidate against the agent's query embedding. This surfaces the most *relevant* records from the structurally valid candidate set.
+
+**Step 4 — Return to agent.** The sorted, scored result set is returned. The agent reasons over structured records — not raw text chunks — because RushDB preserves full property context alongside the similarity score.
+
+---
+
+## Self-Awareness Without External Documentation
+
+A central design goal of RushDB is that agents should be able to operate against an unknown or evolving knowledge graph **without any out-of-band schema documentation**. Two mechanisms make this possible:
+
+1. **`__proptypes`** — every Record carries a `__proptypes` field listing the name and type of each property it holds. This makes every record self-describing.
+
+2. **The Ontology API** — aggregates all `__proptypes` metadata across the project and returns it as a schema snapshot. An agent that calls `/ai/ontology/md` at the start of a session receives the full graph schema in a single, token-efficient Markdown string.
+
+Together, these enable a zero-configuration agentic loop:
+
+```
+Boot → call ontology → understand what exists in the graph
+     → construct SearchQuery from real labels/properties
+     → retrieve relevant records
+     → act on structured, typed results
+```
+
+---
+
+## Composing the Retrieval Approaches
+
+The three retrieval approaches are not mutually exclusive — they compose:
+
+| Approach | When to use | Mechanism |
+|---|---|---|
+| **Structural only** | Known labels and property values | `where` filter |
+| **Semantic with pre-filter** | Meaning-based lookup, optionally scoped by structural conditions | `db.ai.search()` with `where` |
+| **Structural + semantic in one query** | Full SearchQuery features (groupBy, collect, multi-hop) alongside similarity scoring | `where` + `vector.similarity` aggregation |
+
+Both `db.ai.search()` and `db.records.find()` support pre-filtering before scoring — choose based on whether you need managed text embedding (`db.ai.search()`) or the full SearchQuery feature set (`db.records.find()`).
+
+→ See [Properties — Composing Faceted and Semantic Search](./properties.md#composing-faceted-and-semantic-search) for code examples.

docs/docs/concepts/billing-model.md

@@ -0,0 +1,66 @@
+---
+sidebar_position: 8
+---
+
+# Billing Model
+
+## Overview
+
+RushDB uses a **Knowledge Units (KU)** billing model. You pay for the structured knowledge RushDB creates and maintains from your data — not for infrastructure, nodes, edges, storage, or compute.
+
+```
+Total KU consumed in billing period × price per KU = your bill
+```
+
+This model aligns cost with value: you pay more only when RushDB is doing more work to organize and serve your data.
+
+## Monthly Billing Cycle
+
+KU consumption resets at the start of each billing period. Your plan includes a base KU allowance. Consumption above the included allowance is billed as overage (Pro and above).
+
+```
+Bill = included KU (flat rate) + overage KU × overage rate
+```
+
+## Plan Comparison
+
+| | Free | Pro | Scale | Enterprise |
+|---|---|---|---|---|
+| Included KU / month | 100,000 | 10,000,000 | Usage-based | Custom |
+| Overage | Not available | Per KU | Per KU | Negotiated |
+| Projects | 2 | Unlimited | Unlimited | Unlimited |
+| Self-hosted support | ✓ | ✓ | ✓ | ✓ |
+| SLA | — | — | ✓ | ✓ |
+| BYOC (own Neo4j / Aura) | ✓ | ✓ | ✓ | ✓ |
+
+## One Metric
+
+KU is the only number that matters for billing. RAM, CPU, storage, node counts, edge counts, and query time are infrastructure concerns — RushDB absorbs them. Your bill reflects the knowledge work done, nothing else.
+
+## Soft and Hard Limits
+
+- **Soft limit**: RushDB sends an alert when you reach 80% of your monthly KU allowance.
+- **Hard limit**: Write operations are blocked when your allowance is exhausted. Read operations continue unaffected.
+- You can configure alerts and caps from the **KU Usage** page in your dashboard.
+
+## Self-Hosted Billing
+
+Self-hosted deployments (`RUSHDB_SELF_HOSTED=true`) have no KU limits and no billing. The OSS engine runs entirely without quota enforcement.
+
+For teams that need the full platform (dashboard, projects, API key management, team members) without usage caps, contact us about an **Enterprise platform license**.
+
+## Changes to Limits Mid-Period
+
+- Upgrading your plan: new KU limit takes effect immediately.
+- Downgrading your plan: new KU limit takes effect at the start of the next billing period.
+- Cancelling: your current allowance remains active until the end of the paid period.
+
+## KU Usage Dashboard
+
+Your KU consumption is visible in real-time on the **KU Usage** page in your workspace dashboard:
+
+- Total KU consumed this month
+- Remaining KU
+- Estimated end-of-month cost
+- Daily consumption trend chart
+- Ingestion and query spike timeline