Zep and HydraDB both use temporal graphs, but they ask engineering teams to build at different layers. Zep packages users, threads, extraction, and Context Blocks into a managed context platform. HydraDB exposes the graph database underneath, so your team can define its own ontology, data boundaries, and workflows.
If your main problem is cross-session conversational memory, Zep offers the shorter path. If memory is one part of a larger company-wide context system, the database layer matters more than the memory API. Zep is a managed context platform with built-in application conventions: users, threads, extraction, Context Blocks, and graph APIs.
Zep created Graphiti, an open-source temporal knowledge graph framework. The managed Zep service runs Graphiti inside a system backed by Zep's proprietary Context Graph Engine.
HydraDB starts at the database layer. Your application maps its graph and retrieval primitives to users, companies, projects, workflows, and domain objects.
Zep provides the managed context workflow. HydraDB gives your team the programmable graph database and context APIs to define the application model.
| Layer or responsibility | Zep | HydraDB |
|---|---|---|
| Product layer | Managed context platform with built-in application conventions | Programmable graph database and context substrate |
| User and conversation model | Built-in users, threads, messages, and user-level memory | Databases and collections that the application maps to customers, users, teams, projects, or environments |
| Graph construction | Managed temporal graph extraction from messages, text, and JSON | Automatic graph extraction or explicit entities and relations through Bring Your Own Graph |
| Custom graph structure | Up to 10 custom entity and 10 custom edge types per graph or project, with one classification per node or edge and optional strict ontology | Application-supplied entities, relations, predicates, namespaces, relation context, and optional temporal details |
| Retrieval | Automatic Context Blocks for user graphs, plus graph search and direct node, edge, and episode access | Hybrid semantic and BM25 retrieval, metadata filtering, graph traversal, and returned graph paths |
| Context delivered to the model | Automatic Context Block for user graphs; direct search and custom assembly for standalone graphs | Retrieved chunks, sources, and graph context for the application to place in its agent or model prompt |
| Storage engine | Bundled proprietary Context Graph Engine | Graph database built on object storage |
| Main engineering trade-off | Adopt Zep's users, threads, extraction pipeline, and Context Block conventions | Define the application model and how the graph fits the product |
Zep handles the user-memory loop from ingestion to retrieval. You send messages, text, or JSON. Zep extracts entities and facts, constructs a temporal knowledge graph, and returns a Context Block for the user. A user graph aggregates context across that user's threads, and thread.get_user_context() selects the context most relevant to the current thread.
Developers can define custom entity and edge types, disable the default ontology, and enable strict ontology during ingestion. Zep limits a graph or project to 10 custom entity types and 10 custom edge types, with up to 10 fields per model. Each node or edge receives one classification, and ontology changes do not automatically re-extract existing data.
You configure graph construction, users, threads, context assembly, and the engine inside Zep's model rather than defining each layer yourself.
HydraDB handles database isolation, asynchronous ingestion, indexing, graph construction, and hybrid retrieval. One query pipeline combines semantic search, BM25, metadata filters, and graph traversal. HydraDB returns retrieved context rather than a final model answer, so your application decides how to assemble context for the agent.
Your team chooses between two graph construction paths:
Bring Your Own Graph fits teams that already maintain an ontology, curated knowledge graph, database export, or deterministic relationship model. You choose the entity types, predicates, namespaces, and relation metadata instead of asking an extraction model to infer them.
HydraDB isolates customers or environments through separate database boundaries. Collections scope data to teams, workspaces, projects, or users within those boundaries. A B2B application can keep shared company knowledge and user-specific memory in the same context system while keeping them in separate databases.
HydraDB does not supply Zep's user and thread data model, so your team owns several application-level decisions:
Automatic extraction and retrieval remove infrastructure work, but your application still defines how users, workflows, permissions, and domain objects map to the graph.
HydraDB separates durable graph state from compute. It keeps hot data in memory, uses NVMe for warm data, and retains colder graph data on object storage.
This design moves retained graph history off provisioned memory and NVMe tiers as it cools. Cold reads introduce object-storage latency, so the database must manage caching, prefetching, and data placement.
The architectural choice matters when the graph extends beyond one user's conversation history. An enterprise ontology, company brain, or agent-action graph can cover documents, tickets, people, projects, permissions, decisions, and years of events. Storage then becomes part of the product decision.
Zep bundles storage and compute inside its managed service. HydraDB separates them, allowing teams to scale durable graph storage independently from the compute and cache tiers used for retrieval.
HydraDB supports agent memory as one application of its graph database, alongside ontologies, company brains, and agent workflows.
Your ontology defines the entities, relationships, and rules that matter to the business. A support system models accounts, tickets, products, incidents, and owners. A clinical system models patients, providers, consent, orders, and evidence. Those domains need different graph structures.
When these relations must be deterministic, Bring Your Own Graph lets you supply the domain graph directly while retaining automatic extraction for less constrained sources.
A company brain connects documents, conversations, projects, people, decisions, and application data. Its graph has to preserve relationships across sources rather than treat every document as an isolated memory.
HydraDB stores shared knowledge at the database level and scopes team, project, or user context through collections. Its query pipeline combines semantic, keyword, metadata, and graph signals when retrieving context.
You can represent tool calls, inputs, outputs, approvals, and effects as entities and relations that form an agent decision trace alongside the context that produced an action. Multiple agents can query and write within the same database and collection scopes. Your application still defines coordination and conflict rules for concurrent actions.
Zep supports standalone graphs for shared data. Its automatic Context Block applies to user graphs, so applications search standalone graphs separately and combine those results with user context.
Zep and HydraDB both model context that changes over time. The difference is who controls the update model.
Zep stores created_at, valid_at, invalid_at, and expired_at on facts. Its extraction pipeline compares new information with existing graph data to determine whether a new fact supersedes an earlier one.
HydraDB's published architecture models knowledge as versioned, relational, and time-aware state through a Git-style temporal graph. You can use HydraDB's extraction pipeline or provide explicit relations through Bring Your Own Graph. In the public BYOG API, applications may attach an optional temporal_details field to each relation.
Yes. HydraDB publishes a LongMemEval-s evaluation that tests long-term interactive memory across extraction, preference, multi-session reasoning, temporal reasoning, and knowledge updates.
| LongMemEval-s evaluation | HydraDB, Gemini 3.0 Pro | Zep baseline, GPT-4o |
|---|---|---|
| Overall accuracy | 90.79% | 71.2% |
| Temporal reasoning | 90.97% | 62.4% |
| Knowledge update | 97.43% | 83.3% |
The evaluation demonstrates an agent-memory implementation on HydraDB. HydraDB used Gemini 3.0 Pro, while the cited Zep baseline used GPT-4o. The scores measure complete system configurations, including each model, prompt, extraction pipeline, and retrieval setup.
Use **Zep** when:
Use **HydraDB** when:
Zep is a managed context platform with built-in application conventions. HydraDB is a programmable graph database for teams defining their own application model and context systems.
Yes. Both use temporal graphs and expose graph APIs. Zep packages them inside a managed context platform, while HydraDB exposes the programmable graph database underneath.
Not at the same API layer. Zep supplies users, threads, and automatic Context Blocks. HydraDB supplies the graph database and retrieval primitives, while your application defines those product-level workflows.
Yes. Zep supports custom entity and edge types, optional strict ontology, user graphs, and standalone graphs. Its managed model limits a graph or project to 10 custom entity types and 10 custom edge types, with up to 10 fields per model and one classification per node or edge.
No. HydraDB also handles ingestion, automatic graph extraction, hybrid retrieval, metadata filtering, graph traversal, and response shaping. Bring Your Own Graph lets you replace extraction with explicit entities and relations for selected sources.
Your team defines how databases, collections, entities, and relations map to the product. You also own the agent, prompt, user experience, and application-specific policies around the retrieved context.
Use Zep when the chatbot can adopt its user, thread, and Context Block model directly. Use HydraDB when chatbot memory belongs to a larger system with shared knowledge, custom domain relationships, or other graph applications. Zep stores four timestamps on facts and lets its extraction pipeline determine whether new information supersedes an earlier fact. HydraDB models versioned, time-aware graph state and accepts explicit BYOG relations with an optional temporal_details field.
Yes, but the workflow differs. Zep applications search standalone graphs separately from the automatic user Context Block. HydraDB applications map shared and private context across databases and collections. In both systems, your application coordinates concurrent agent actions.
HydraDB keeps hot graph data in memory, uses NVMe for warm data, and retains colder graph data on object storage. That keeps retained graph history separate from the compute and local-storage tiers used for query execution and caching.