{"slug": "hydradb-vs-zep-managed-context-platform-vs-programmable-graph-database", "title": "HydraDB vs Zep: Managed Context Platform vs Programmable Graph Database", "summary": "HydraDB and Zep both leverage temporal graphs for AI agent memory, but they target different engineering layers. Zep offers a managed context platform with built-in users, threads, and Context Blocks, while HydraDB provides a programmable graph database that lets teams define their own ontology and workflows. The choice depends on whether the primary need is cross-session conversational memory or a broader company-wide context system.", "body_md": "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.\n\nIf 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](https://hydradb.com/blog/ai-agent-memory-context-database-problem).\n\n[Zep](https://help.getzep.com/concepts) is a managed context platform with built-in application conventions: users, threads, extraction, Context Blocks, and graph APIs.\n\nZep created [Graphiti](https://help.getzep.com/zep-vs-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.\n\nHydraDB starts at the database layer. Your application maps its graph and retrieval primitives to users, companies, projects, workflows, and domain objects.\n\nZep provides the managed context workflow. HydraDB gives your team the programmable graph database and context APIs to define the application model.\n\n| Layer or responsibility | Zep | HydraDB |\n|---|---|---|\n| Product layer | Managed context platform with built-in application conventions | Programmable graph database and context substrate |\n| 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 |\n| Graph construction | Managed temporal graph extraction from messages, text, and JSON | Automatic graph extraction or explicit entities and relations through Bring Your Own Graph |\n| 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 |\n| 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 |\n| 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 |\n| Storage engine | Bundled proprietary Context Graph Engine | Graph database built on object storage |\n| 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 |\n\nZep 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.\n\nDevelopers can define [custom entity and edge types](https://help.getzep.com/customizing-graph-structure), 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.\n\nYou configure graph construction, users, threads, context assembly, and the engine inside Zep's model rather than defining each layer yourself.\n\nHydraDB handles database isolation, asynchronous ingestion, indexing, graph construction, and hybrid retrieval. One query pipeline [combines semantic search, BM25, metadata filters, and graph traversal](https://hydradb.com/blog/btree-vector-graph-hybrid-search-storage-layer). HydraDB returns retrieved context rather than a final model answer, so your application decides [how to assemble context for the agent](https://hydradb.com/blog/replace-prompt-stuffing-markdown-files).\n\nYour team chooses between two graph construction paths:\n\nBring 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.\n\nHydraDB isolates customers or environments through separate [database boundaries](https://hydradb.com/blog/multi-tenant-ai-agent-database). 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.\n\nHydraDB does not supply Zep's user and thread data model, so your team owns several application-level decisions:\n\nAutomatic extraction and retrieval remove infrastructure work, but your application still defines how users, workflows, permissions, and domain objects map to the graph.\n\nHydraDB [separates durable graph state from compute](https://hydradb.com/blog/ai-context-graph-ontology-infrastructure). It keeps hot data in memory, uses NVMe for warm data, and retains colder graph data on object storage.\n\nThis 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.\n\nThe 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.\n\nZep 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.\n\nHydraDB supports agent memory as one application of its graph database, alongside ontologies, company brains, and agent workflows.\n\nYour 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.\n\nWhen these relations must be deterministic, [Bring Your Own Graph](https://docs.hydradb.com/essentials/v2/bring-your-own-graph) lets you supply the domain graph directly while retaining automatic extraction for less constrained sources.\n\nA [company brain](https://hydradb.com/blog/build-company-brain-ai-agents) 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.\n\nHydraDB 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.\n\nYou can represent tool calls, inputs, outputs, approvals, and effects as entities and relations that form an [agent decision trace](https://hydradb.com/blog/ai-agent-decision-traceability-auditability) 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.\n\nZep 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.\n\nZep and HydraDB both model context that changes over time. The difference is who controls the update model.\n\n[Zep stores](https://help.getzep.com/facts) 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.\n\nHydraDB's [published architecture](https://research.hydradb.com/hydradb) models knowledge as versioned, relational, and time-aware state through a [Git-style temporal graph](https://hydradb.com/blog/git-for-context-versioned-temporal-graphs-ai-agent-memory). 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.\n\nYes. HydraDB publishes a [LongMemEval-s evaluation](https://research.hydradb.com/hydradb) that tests long-term interactive memory across extraction, preference, multi-session reasoning, temporal reasoning, and knowledge updates.\n\n| LongMemEval-s evaluation | HydraDB, Gemini 3.0 Pro | Zep baseline, GPT-4o |\n|---|---|---|\n| Overall accuracy | 90.79% | 71.2% |\n| Temporal reasoning | 90.97% | 62.4% |\n| Knowledge update | 97.43% | 83.3% |\n\nThe 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.\n\nUse **Zep** when:\n\nUse **HydraDB** when:\n\nZep 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.\n\nYes. Both use temporal graphs and expose graph APIs. Zep packages them inside a managed context platform, while HydraDB exposes the programmable graph database underneath.\n\nNot 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.\n\nYes. 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.\n\nNo. 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.\n\nYour 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.\n\nUse 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.\n\nZep 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.\n\nYes, 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.\n\nHydraDB 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.", "url": "https://wpnews.pro/news/hydradb-vs-zep-managed-context-platform-vs-programmable-graph-database", "canonical_source": "https://dev.to/hydra_db_blogs/hydradb-vs-zep-3033", "published_at": "2026-08-14 20:12:36+00:00", "updated_at": "2026-08-14 20:36:24.222550+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["HydraDB", "Zep", "Graphiti"], "alternates": {"html": "https://wpnews.pro/news/hydradb-vs-zep-managed-context-platform-vs-programmable-graph-database", "markdown": "https://wpnews.pro/news/hydradb-vs-zep-managed-context-platform-vs-programmable-graph-database.md", "text": "https://wpnews.pro/news/hydradb-vs-zep-managed-context-platform-vs-programmable-graph-database.txt", "jsonld": "https://wpnews.pro/news/hydradb-vs-zep-managed-context-platform-vs-programmable-graph-database.jsonld"}}