HydraDB vs Zep: Managed Context Platform vs Programmable Graph Database

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. TL;DR Choose Zep when you want a managed context platform with built-in users, threads, temporal extraction, and Context Blocks. Choose HydraDB when you want to define your own application model on a programmable graph database that serves memory, company knowledge, workflow context, and agent action history. Managed context platform or programmable graph database? 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. What each product provides 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 What Zep handles for your application 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. What HydraDB leaves under your control 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: Automatic extraction. HydraDB extracts entities and relations during ingestion and traverses them during retrieval. Bring Your Own Graph. You send explicit entities and relations with each source and skip LLM graph extraction for that source. HydraDB stores and queries the supplied graph in the same shape as an extracted graph. 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. What your team still owns on HydraDB HydraDB does not supply Zep's user and thread data model, so your team owns several application-level decisions: The application-level model for users, threads, workflows, and business objects The ontology and deterministic relationship rules used with Bring Your Own Graph The entity-resolution and conflict rules for graph state the application supplies The prompt, agent, and user experience that consumes retrieved context The evaluation logic for deciding whether the returned context supports the next action Automatic extraction and retrieval remove infrastructure work, but your application still defines how users, workflows, permissions, and domain objects map to the graph. Where object storage changes the architecture 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. Beyond agent memory: ontologies, company brains, and agent actions HydraDB supports agent memory as one application of its graph database, alongside ontologies, company brains, and agent workflows. Ontologies 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. Company brains 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. Agent actions and shared 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. How both systems handle changing facts 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. Can you build agent memory on HydraDB? 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. When to choose Zep vs HydraDB Use Zep when: You want managed users, threads, memory ingestion, temporal graph construction, and Context Blocks. Your main problem is cross-session agent memory or personalized context. You want to configure a managed system instead of designing the database and application model around it. Zep's extraction ontology and graph APIs fit your domain model. Use HydraDB when: You want a graph database to serve as the foundation for your context system. You need to supply explicit entities and relations or combine automatic extraction with a curated graph. Your context spans memory, company knowledge, ontologies, workflow context, and agent action history. You want databases and collections to map directly to customer, workspace, team, project, and user boundaries. FAQ What's the main difference between HydraDB and Zep? 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. Are Zep and HydraDB both graph-native? 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. Can HydraDB replace Zep directly? 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. Does Zep support custom ontologies and shared graphs? 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. Is HydraDB only a low-level graph store? 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. What does your team build when using HydraDB for agent memory? 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. Which option fits a chatbot that needs cross-session memory? 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. How do HydraDB and Zep handle temporal context? 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. Can several agents share context in Zep and HydraDB? 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. Why does HydraDB use object storage? 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.