RushDB
Push any JSON. Get graph relationships and vector search instantly — no schema, no pipeline, no setup.
Start building free →FAQ
Every new agent needs a prompt explaining your tables and fields. RushDB lets agents fetch a structured snapshot of the live graph at runtime.
RushDB 2.0 is a major release built for the agentic era: native semantic search, ontology-aware querying, MCP with OAuth, bring-your-own Neo4j, and prebuilt agent skills. It turns memory infrastructure into one unified layer, so developers can store structured context, traverse relationships, and search by meaning without stitching together multiple systems.
Most teams building LLM-powered applications start with a single goal: get data in front of the model. They end up with five jobs.
The first pipeline extracts and transforms raw data into a warehouse. The second generates embeddings and pushes them to a vector store. The third syncs structured records into a graph or relational database. The fourth builds search indexes for full-text retrieval. The fifth maintains a metadata catalog so the system knows what it can query.
None of these pipelines is accidental. Each one exists because LLM applications have genuinely different retrieval requirements that no single traditional store was designed to satisfy simultaneously. The operational cost—synchronization bugs, deployment complexity, cross-system latency—is the structural consequence of that mismatch.
This article explains why those five pipelines emerge, what each one is actually doing, and how RushDB's architecture collapses them into a single ingestion flow that produces a structured graph, managed embedding indexes, and a live schema layer in one operation.
To understand why fragmentation happens, it helps to trace the data path of a concrete AI application—say, an agent that helps engineers navigate a company's infrastructure knowledge base.
Pipeline 1: ETL into a warehouse. Raw data arrives as JSON events, Markdown documents, API responses, and database exports. Before anything else can use it, this data must be cleaned, typed, and loaded into a queryable store. Teams reach for tools like Fivetran, dbt, or custom ingestion scripts feeding into Snowflake or BigQuery. The output is structured rows, but the store is optimized for analytical queries, not low-latency retrieval or graph traversal.
Pipeline 2: Embedding generation. LLM retrieval requires semantic similarity, which means converting text fields into dense vectors. This is a separate compute job: call an embedding API (OpenAI, Cohere, or a self-hosted model), receive float arrays, and write them somewhere. The embedding job must run on every new document and re-run when the embedding model changes. The output lives in a dedicated vector store like Pinecone or Weaviate, or in a vector extension like pgvector on PostgreSQL Pinecone Documentation – Product Overview Weaviate Documentation – Developers Overview pgvector – Open-source Vector Similarity Extension for PostgreSQL.
Pipeline 3: Graph sync. Relationships between entities—which engineer owns which service, which ticket references which component—are not naturally represented in flat rows or vector indexes. Teams add a graph database (often Neo4j) or build a relational schema with foreign keys. Keeping this store in sync with the warehouse requires a third pipeline: change-data-capture, scheduled exports, or application-layer dual-writes.
Pipeline 4: Search index builds. Full-text search over document content requires yet another system. Elasticsearch and OpenSearch both support dense vector fields alongside inverted indexes Elasticsearch Reference – dense_vector field type OpenSearch Documentation – k-NN Search, but they are typically deployed as separate infrastructure from the graph and the warehouse. Index builds must be triggered on ingestion and kept consistent with the source of truth.
Pipeline 5: Metadata and schema catalog. Agents need to know what they can query. Which labels exist? What properties does each record type carry? What are the valid value ranges for a numeric filter? Without a live schema layer, agents either hallucinate query structure or require hand-written tool descriptions that drift out of date. Teams build internal catalogs, OpenAPI specs, or prompt-engineering workarounds to paper over this gap.
The result is a stack where a single write to the source system fans out into five asynchronous jobs across five different stores. Any one of them can fall behind. When the graph and the vector store diverge—a record deleted from one but not the other—retrieval produces inconsistent results that are difficult to diagnose. Orchestration frameworks like LangChain and LlamaIndex LangChain Python Documentation – Introduction abstract over these backends through integrations and chains, but they do not eliminate the underlying synchronization problem. The databases still run independently; the framework only hides the seams at query time.
Vector databases can store metadata, filters, identifiers, and provenance alongside embeddings Pinecone Documentation – Product Overview Weaviate Documentation – Developers Overview, which helps with some retrieval patterns. But metadata stored in a vector index is not the same as connected context traversed natively in a graph. When an agent needs to follow a relationship—find all memories belonging to a specific agent, then filter by topic and recency—that traversal either happens in application logic across two systems or requires the graph to be the authoritative store with vectors kept in sync beside it. Neither option eliminates the synchronization burden; they only move it.
The diagram below contrasts these two worlds: the traditional five-pipeline fan-out on the left, and RushDB's single-ingestion path on the right.
RushDB is a graph and vector database built on Neo4j, designed for AI-native workloads GitHub - rush-db/rushdb: RushDB is a graph + vector database and memory layer for AI agents. Push any JSON, get typed, searchable, relationship-aware records back — no schema, no migrations. Built on Neo4j.. Neo4j serves as the underlying storage and transaction engine; RushDB exposes its own data model, APIs, and SDKs on top of it Neo4j Live: RushDB in Action - Graph-Native Tools for the AI Era.
The data model RushDB implements is the Labeled Meta Property Graph (LMPG)—distinct from a plain Labeled Property Graph. In a standard LPG, properties are key-value pairs attached to nodes and edges. In RushDB's LMPG, properties are elevated into first-class graph structures called HyperProperties: each property has its own identity, type metadata, and value range information that the system tracks and exposes. This means the schema is not a separate catalog bolted on afterward—it is a structural consequence of how data is stored.
On top of Neo4j's transactional engine and the LMPG model, RushDB provides three layers that replace the five pipelines:
Ingestion layer. A single importJson / import_json call accepts arbitrary nested JSON, infers types, maps relationships from nested structure, assigns labels, and writes typed records into the graph—no schema definition required, no migrations GitHub - rush-db/rushdb: RushDB is a graph + vector database and memory layer for AI agents. Push any JSON, get typed, searchable, relationship-aware records back — no schema, no migrations. Built on Neo4j..
Embedding index layer. After ingestion, any string property can be designated for semantic search by creating a managed embedding index. RushDB handles embedding generation and storage internally. Alternatively, teams can supply their own pre-computed vectors through an external index. Either way, vector similarity search runs against the same records that graph queries address Features | RushDB.
Live schema layer. Because properties are first-class structures in the LMPG, RushDB can expose a live schema at any time: labels, record counts, property names with types and value ranges, and cross-label relationships with direction. This schema is available as structured JSON for programmatic use or as compact Markdown tables sized for LLM context windows Features | RushDB.
The practical effect is that the five pipelines collapse into one ingestion call, with the embedding and schema layers activated through configuration rather than separate infrastructure.
The mechanism is easier to understand with a concrete example. Consider an AI agent that stores memories about user interactions. Each memory has a text content field, a numeric importance score, a status, and a topic. In a five-pipeline stack, this data would flow through ETL into a warehouse, get embedded separately, and be synced to a graph with a schema defined upfront.
With RushDB, the same data is pushed once:
{
"AGENT_MEMORY": [
{
"id": "mem_001",
"agentId": "agent_alpha",
"content": "User requested assistance with setting up a Kubernetes cluster on AWS.",
"importance": 0.9,
"timestamp": 1710000000,
"topic": "Infrastructure",
"status": "active",
"min": 0,
"max": 1
},
{
"id": "mem_002",
"agentId": "agent_alpha",
"content": "User mentioned they prefer Terraform over CloudFormation for IaC.",
"importance": 0.8,
"timestamp": 1710005000,
"topic": "Infrastructure",
"status": "active",
"min": 0,
"max": 1
},
{
"id": "mem_003",
"agentId": "agent_beta",
"content": "Discussed marketing strategy and social media scheduling tools.",
"importance": 0.4,
"timestamp": 1710010000,
"topic": "Marketing",
"status": "archived",
"min": 0,
"max": 1
}
]
}
The suggestTypes: true option instructs RushDB to infer property types from the values—importance becomes a number, content becomes a string, status becomes a string. The returnResult: true option returns the created records in the response so the caller can inspect them immediately.
After this single call, the ingestion layer has:
AGENT_MEMORY nodes in Neo4jNo schema was defined beforehand. No migration was run. The graph structure and the schema catalog were produced as a side effect of the write.
Once records exist, the three layers become independently useful.
The properties API returns the schema that was inferred during ingestion:
properties = db.properties.find({})
print(json.dumps(properties["data"], indent=2))
The response lists every property across all AGENT_MEMORY records—agentId, content, importance, status, timestamp, topic—each with its inferred type and a count of how many records carry that property. An agent receiving this output knows exactly what it can filter on without any hand-written tool description.
For numeric properties, the schema layer goes further. Calling properties.values() on the importance property returns the actual distribution:
properties = db.properties.find({})
facet = next(prop for prop in properties["data"] if prop["name"] == "importance")
values = db.properties.values(facet["id"])
print(json.dumps(values["data"], indent=2))
The response includes min: 0.4, max: 0.9, and the discrete values [0.4, 0.8, 0.9]. An agent constructing a filter like importance > 0.7 can validate that range before executing the query, rather than discovering at runtime that no records match.
For agents consuming schema in bulk, db.ai.get_schema_markdown() returns a compact Markdown table that includes a Semantic Search column per property—showing managed cosine 1536d [ready] for indexed properties or — for unindexed ones. This format is sized for LLM context windows and lets a model reason about which properties support semantic retrieval versus structured filtering Features | RushDB.
One operational note: the schema returned by get_schema and get_schema_markdown may reflect a cached snapshot up to one hour old. The cache exists because computing cross-label relationship statistics over large graphs is expensive.
Semantic search over the content field requires an embedding index. Creating one is a single API call:
index = db.ai.indexes.create({
"sourceType": "managed",
"label": "AGENT_MEMORY",
"propertyName": "content"
})
print(json.dumps(index["data"], indent=2))
The response confirms status: "ready" and indexedRecords: 3—all three memories were embedded and indexed. There was no separate embedding service to call, no vector store to provision, and no sync job to schedule. The embedding index is a policy attached to a property within the same database that holds the records.
With the index in place, semantic search can be combined with property filters in a single query:
hits = db.records.vector_search({
"labels": [
"AGENT_MEMORY"
],
"propertyName": "content",
"query": "Infrastructure deployment tools",
"where": {
"status": "active"
}
})
print(json.dumps({"total": hits.total, "data": [record.data for record in hits.data]}, indent=2))
{
"data": [
{
"__label": "AGENT_MEMORY",
"__score": 0.78,
"agentId": "agent_alpha",
"content": "User mentioned they prefer Terraform over CloudFormation for IaC.",
"id": "mem_002",
"importance": 0.8,
"max": 1,
"min": 0,
"status": "active",
"timestamp": 1710005000,
"topic": "Infrastructure"
},
{
"__label": "AGENT_MEMORY",
"__score": 0.8,
"agentId": "agent_alpha",
"content": "User requested assistance with setting up a Kubernetes cluster on AWS.",
"id": "mem_001",
"importance": 0.9,
"max": 1,
"min": 0,
"status": "active",
"timestamp": 1710000000,
"topic": "Infrastructure"
}
]
}
The query returns the two active infrastructure memories—mem_001 (Kubernetes on AWS, __score: 0.80) and mem_002 (Terraform vs CloudFormation, __score: 0.78)—and excludes mem_003 because its status is "archived". The where filter ran inside the database against the graph properties; it was not applied as a post-processing step in application code after fetching all vector matches.
This is the meaningful architectural distinction. In a five-pipeline stack, the vector store returns candidate IDs ranked by similarity, and the application then queries the graph or relational store to apply structured filters and fetch full records. That round-trip introduces latency and requires the two stores to agree on record identity. Here, both operations execute against the same underlying Neo4j instance through RushDB's unified query layer.
Captured from a run against an isolated RushDB project in Python and TypeScript; volatile record identifiers are normalized.
Execute Vector Search with Metadata Filters
{
"data": [
{
"__label": "AGENT_MEMORY",
"__score": 0.78,
"agentId": "agent_alpha",
"content": "User mentioned they prefer Terraform over CloudFormation for IaC.",
"id": "mem_002",
"importance": 0.8,
"max": 1,
"min": 0,
"status": "active",
"timestamp": 1710005000,
"topic": "Infrastructure"
},
{
"__label": "AGENT_MEMORY",
"__score": 0.8,
"agentId": "agent_alpha",
"content": "User requested assistance with setting up a Kubernetes cluster on AWS.",
"id": "mem_001",
"importance": 0.9,
"max": 1,
"min": 0,
"status": "active",
"timestamp": 1710000000,
"topic": "Infrastructure"
}
]
}
It is worth being precise about what RushDB replaces and what it does not.
Orchestration frameworks (LangChain, LlamaIndex). These tools LangChain Python Documentation – Introduction abstract over multiple backends through integrations: a LangChain retriever can query Pinecone for vectors, then call a separate graph database for context, then merge results in application code. This approach works and is widely deployed. The limitation is that the underlying databases still operate independently. A document deleted from the graph is not automatically removed from the vector index; the orchestration layer has no mechanism to enforce that consistency. RushDB's approach is different in kind: it collapses the storage layer itself so there is no cross-system synchronization to manage. Orchestration frameworks and RushDB are not mutually exclusive—an agent built with LangChain or LlamaIndex can use RushDB as its memory backend.
Vector databases (Pinecone, Weaviate). Dedicated vector stores Pinecone Documentation – Product Overview Weaviate Documentation – Developers Overview are optimized for high-dimensional similarity search at scale and offer features like multi-tenancy, namespace isolation, and fine-grained index tuning that RushDB's managed embedding layer does not currently expose. They can store metadata alongside vectors, which supports filtered retrieval. What they do not provide is native graph traversal: following a relationship from a memory to its owning agent, then to other memories that agent has stored, requires either application-layer joins or a separate graph database. Teams with very large embedding corpora or specialized ANN index requirements may still reach for a dedicated vector store.
Vector extensions for relational databases (pgvector, Elasticsearch dense vectors). Adding pgvector to PostgreSQL pgvector – Open-source Vector Similarity Extension for PostgreSQL or using Elasticsearch's dense_vector field type Elasticsearch Reference – dense_vector field type gives a single store that handles both structured queries and approximate nearest-neighbor search. This reduces the number of systems but does not provide graph traversal semantics. Complex relationship queries still require multi-table joins, and the schema catalog remains implicit in the table definitions rather than being a live, queryable structure. OpenSearch's k-NN plugin OpenSearch Documentation – k-NN Search follows the same pattern. These are reasonable choices for teams already invested in PostgreSQL or Elasticsearch whose relationship queries are simple enough to express as joins.
The practical question is not which approach is universally correct but which one matches the query patterns of a given application. If an agent needs to traverse connected context—follow relationships, filter by property ranges, and rank by semantic similarity in one operation—a unified graph-plus-vector store reduces the coordination surface. If the workload is primarily similarity search with simple metadata filters and the corpus is very large, a dedicated vector store may be the right fit.
RushDB's single-ingestion model carries trade-offs that matter for production decisions.
Schema cache latency. The get_schema and get_schema_markdown APIs may return a snapshot up to one hour old. For applications where schema changes are frequent—rapid prototyping, high-velocity ingestion of new record types—agents may query against a schema that does not yet reflect the latest labels or properties.
Managed embedding index scope. The managed embedding index handles embedding generation internally, which simplifies operations but means the embedding model is chosen by RushDB rather than the application. Teams that need a specific embedding model for domain-specific recall, or that want to bring pre-computed vectors from a fine-tuned model, can use the external index path (sourceType: "external") and supply vectors via upsert_vectors. This preserves flexibility but reintroduces an external embedding step.
Graph traversal depth and scale. RushDB inherits Neo4j's strengths for connected data traversal, but very large graphs with deep multi-hop traversals carry the same performance considerations as any graph database. The LMPG model's HyperProperty catalog adds overhead compared to a plain property graph because properties are first-class nodes. For workloads that are purely flat-record retrieval with no relationship traversal, a simpler store may have lower operational overhead.
Not a universal replacement. RushDB is positioned as a graph and vector database for AI agent memory and LLM application backends GitHub - rush-db/rushdb: RushDB is a graph + vector database and memory layer for AI agents. Push any JSON, get typed, searchable, relationship-aware records back — no schema, no migrations. Built on Neo4j.. It is not a data warehouse, a streaming pipeline, or a full-text search engine with the tuning surface of Elasticsearch. Teams that need analytical aggregations over billions of rows, complex stream processing, or advanced relevance tuning for search-as-a-service workloads will still reach for specialized systems. The five-pipeline stack may shrink—ETL into a warehouse can remain for analytical workloads while RushDB handles the agent memory and retrieval layer—but it does not necessarily disappear entirely.
The five-pipeline tax is not a consequence of poor tooling choices. It emerges because LLM applications genuinely need structured relationships, semantic similarity, and live schema introspection—capabilities that were historically distributed across separate systems optimized for different access patterns.
RushDB's architecture addresses this at the storage layer rather than the orchestration layer. By implementing the Labeled Meta Property Graph model on top of Neo4j, it makes properties first-class structures that carry type metadata and value ranges as a side effect of ingestion. By attaching managed embedding indexes to string properties within the same database, it eliminates the separate embedding pipeline and the synchronization risk between vector and graph stores. By exposing a live schema API—including a Markdown format sized for LLM context—it replaces the metadata catalog with a queryable structure that updates as data changes Features | RushDB GitHub - rush-db/rushdb: RushDB is a graph + vector database and memory layer for AI agents. Push any JSON, get typed, searchable, relationship-aware records back — no schema, no migrations. Built on Neo4j..
The result is that pushing JSON once yields a typed graph, searchable embedding indexes, and a schema layer that agents can introspect and query through a single contract. Whether that contract is sufficient for a given production workload depends on the embedding model requirements, the scale of the vector corpus, and the complexity of the analytical queries involved. But for the common case—an AI agent that needs to store, retrieve, and reason over connected structured data—the five pipelines can become one.