---
title: "past.dev vs Zep"
description: "Zep and past.dev both put time on the fact. Where they differ: the open-source engine, the database underneath, what ingestion takes in, and what the read surface returns."
canonical: https://past.dev/vs/zep
last-updated: 2026-08-26
---
# past.dev vs Zep

Source: https://past.dev/vs/zep

Zep and past.dev share a premise most memory products do not: a fact needs a validity window, so a superseded value is invalidated rather than overwritten. Zep is built on Graphiti, its open-source temporal graph engine, which runs on a dedicated graph database. past.dev is a hosted API over a temporal graph on Postgres with pgvector, with an answer endpoint that returns evidence, per-call cost and an explicit abstention. If you want to own and run the engine yourself, Graphiti is the stronger starting point.

## What Zep is

Zep is a managed memory service for agents, built on [Graphiti](https://github.com/getzep/graphiti), an Apache 2.0 framework the same team maintains. Graphiti ingests data as episodes, derives entity nodes and relationship edges, and gives each fact a validity window: when information changes, the old fact is invalidated rather than deleted, and every derived fact traces back to the episode it came from. It runs on Neo4j, FalkorDB and Amazon Neptune. The team published the architecture as a paper on temporal knowledge graphs for agent memory.

## What past.dev is

A hosted API over the same idea, with a different surface and a different operational footprint. Ingestion takes raw text plus the timestamp it happened, backdatable, with no schema to declare. The graph is maintained on Postgres with pgvector, which is also what the self-host image runs, so a customer deployment needs no graph database in addition to the Postgres it already operates.

The read surface is where the difference is most visible. `/recall` returns ranked evidence with sources and a token budget rather than a result count. `/answer` returns a grounded answer, the evidence behind it, the dollar cost of that call, and `abstained: true` rather than a guess when the graph does not establish an answer.

## Architecture differences

|  | Zep | past.dev |
| --- | --- | --- |
| Open-source engine | Graphiti, Apache 2.0 | No open-source engine; a self-host image of the product |
| Storage underneath | Neo4j, FalkorDB or Amazon Neptune | Postgres with pgvector |
| Time model | Bi-temporal, facts invalidated rather than deleted | Facts carry validity windows, previous values kept as history |
| What you send | Episodes: messages, text or JSON | Text plus the timestamp it happened, backdatable |
| Read surface | Retrieval of facts and context | `/recall` for evidence, `/answer` for a grounded answer |
| Abstention | Your code decides | `abstained: true` on `/answer` |
| Cost visibility | Plan-level | Reported per call in the response |
| Self-host | Run Graphiti yourself, with your own graph database | The same image we run, on your Docker and your Postgres |

## How to choose

Both are reasonable choices and they are not built for the same job. The short version:

- **Choose Zep or Graphiti** if you want the engine itself under an open-source licence, if you are already running a graph database, or if you want to write the traversals yourself.
- **Choose past.dev** if you want the memory as an API rather than as infrastructure, if you want an answer endpoint that abstains and reports its cost, or if adding a graph database to your stack is the part you are trying to avoid.
- **Both** put time on the fact, which is the property that separates either from a vector store. [Knowledge graphs for LLM applications](/knowledge-graph-for-llm) explains why that matters.

## What this page does not claim

No head-to-head numbers. We run LoCoMo on the community-corrected answer keys, LongMemEval and BEAM, with full-context and plain-RAG baselines and several judges, and the method is published on [benchmarks](/benchmarks). A comparison against another product is only worth reading if the other product was configured by someone who wanted it to do well, and if the harness that produced it can be rerun. Until we publish that harness, this page compares designs, not scores. The numbers land here when they can be reproduced.

## Related

- [Knowledge graphs for LLM applications](https://past.dev/knowledge-graph-for-llm)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [past.dev vs mem0](https://past.dev/vs/mem0)
- [How the pipeline works](https://past.dev/docs/memory-api/how-it-works)
- [How we measure memory](https://past.dev/benchmarks)