Relative significance
Insert events dynamically relative to their neighbours —
ABOVE, BELOW, or
BETWEEN — with no rigid, static importance scale to
maintain.
Finite memory, done right
Hippocampus is a storage engine that automatically keeps your most significant records and gracefully forgets the rest — bounded retention with no TTL rules to maintain. It weighs significance, recall, and relationships instead of age, giving log pipelines, compliance trails, and AI agents a long-term memory that stays useful as it grows.
Traditional stores lean on TTLs and FIFO queues, where age alone decides what survives. Hippocampus applies principles of human memory consolidation instead.
Insert events dynamically relative to their neighbours —
ABOVE, BELOW, or
BETWEEN — with no rigid, static importance scale to
maintain.
Querying or accessing a record strengthens its retention weight, protecting high-demand operational data from decay.
Periodic background cycles apply decay models, compact space, and distil clusters of episodic detail into compact semantic summaries.
Embedded or centralised, backed by SQLite, PostgreSQL, or MySQL — with minimum retention floors that hold regardless of storage pressure.
Give it a capacity target in rows or bytes and the decay threshold scales with how full the store is: forgetting sharpens as space runs short and eases when it does not. A memory can also declare the bytes it merely points at, so the same pressure governs a payload this store never holds.
Ask what the next cycle would forget before it runs, ask any single memory where it stands and how long it has left, and keep a log of what went, with the value and the threshold that decided it. An outbound callback can tell whatever owns the payload behind a memory that it is about to go.
Hippocampus is infrastructure, not a walled garden — it speaks the protocols your services and agents already use, runs on the database you already operate, and layers optional integrations on top.
Talk to it over an HTTP/JSON gateway or
gRPC, browse the embedded web console, use the
CLI, or give an AI agent long-term memory through the built-in
Model Context Protocol (MCP)
server — works with Claude, ChatGPT, Grok, or any MCP host.
Python has a published client —
pip install hippocampus-client, covering the full RPC surface and released from the same tag
as the contract it was generated from. Any other language with a
gRPC or HTTP stack gets a client in minutes:
generate one
from the proto or the served OpenAPI document.
The same engine runs embedded on pure-Go SQLite (WAL) or centralised on PostgreSQL or MySQL — one consolidating node alongside any number of stateless read/write replicas.
The streams your systems already emit become long-lived, consolidating memories with no extra plumbing. Event-sourcing connectors ingest from Kafka, NATS, RabbitMQ, and MQTT, and an OpenTelemetry Collector exporter turns log records into memories, with severity driving significance. At the edge, the ingestor stages data locally and promotes only what earns it: when an event completes, a rules engine decides whether it reaches the central store whole, condensed, or not at all.
Keyword search over memory content works on every driver with nothing to configure and no cluster to run. Point the engine at OpenSearch and an embedding model and the same call also does semantic and hybrid retrieval — meaning, not only matching words. Summarisation works the same way: the sleep cycle can distil a finished event into a single memory by itself, against a local Ollama or any OpenAI-compatible endpoint.
An
Obsidian
plugin uses Hippocampus as the storage backend for your vault,
so your notes live in the same engine as the rest of your
long-term memory. For agents, the
LlamaIndex
adapter (llama-index-memory-hippocampus, over the
published Python client) drops in as a long-term memory block
whose retrieval reinforces what it returns: a fact the
agent keeps reaching for survives by being used, and one it
never retrieves decays out — no eviction policy, no cap, no TTL
to maintain.
Ship it the way you already ship everything. A Homebrew tap, .deb / .rpm packages with a hardened systemd unit, a macOS LaunchAgent, Docker Compose files, and Kubernetes (Kustomize) bases are all maintained in-repo, and the multi-arch image runs anywhere a container does. Before any of that, the configuration builder writes the config and the deployment artefacts for you, in your browser.
Metrics and traces leave over OTLP, or the same metrics are served for Prometheus to scrape — no collector in the middle just to change protocol. The alert rules and a Grafana dashboard ship with the source, health and readiness probes are built in, and a topology view shows what an instance is attached to — stores, search, model endpoints, peers, bridges — and the last known health of each.
A single pure-Go binary, published multi-arch (amd64 + arm64), with OIDC (Auth0, Keycloak, or any provider), JWT, and TLS throughout. Per-RPC reader/writer/admin tiers say what a caller may do; optional group scoping says which records they may do it to, so teams can share one store without sharing their memories. When one of them leaves, deletion by predicate drains their records by group, time, or metadata rather than by id — the filter that lists them is the filter that deletes them.
The consoles run a compressed decay clock, so forgetting,
summarisation, and eviction play out in minutes or hours rather than
days. The Bluesky one is the only demo running on data nobody here
controls — real posts, real attention, arriving live. Sign in as
demo / demo to browse — the consoles are
read-only for visitors. Each opens in a new tab, so this page stays
where it is.
These consoles are a lens on the engine, not the product itself. Hippocampus is a memory store you run behind your own systems — the UI is just one way to watch it work.
One writer sends byte-for-byte identical memories to two stores — same ids, same bodies, arriving and recalled at the same moments. The only difference is that one of them is told which memories matter. Search both for something old and important: it is still in one and gone from the other. Everything else about them is the same, right down to the configuration file.
A small language model reads the Bluesky feed, recalls what it already concluded, and writes one observation — rating how much that observation matters. The rating becomes its significance, so what the agent called trivia is gone within a day and what it called a landmark is still there a month later. Its judgement, not ours.
Open the observer consoleHeadlines from verified news organisations stream in from Bluesky, every one arriving equally significant. Likes and reposts reinforce them, the conversation each draws is kept with it as a thread, related coverage is linked so a story survives as a cluster — and everything else quietly decays, sorted purely by what people came back to.
Open the Bluesky consoleGreat Expectations is reloaded daily, then summarised and left to decay. Watch clusters of episodic memories consolidate into semantic summaries as the store forgets the rest.
Open the book consoleA shared Grafana charts both stacks live — memory counts, consolidation and eviction rates, decay, and request latency — so you can see the engine working from the outside as it forgets and summarises.
Open Grafana
Prefer to run it yourself?
Clone the repo and start the embedded stack — pure-Go SQLite, zero
external dependencies — then watch the same behaviour on your own
machine.
git clone https://github.com/fastbean-au/hippocampus.git
cd hippocampus
./demo/run.sh
It's a single pure-Go binary — SQLite embedded for a self-contained node, or PostgreSQL / MySQL for a centralised store. Install it the way you already install everything else.
Pick a path below, or let the builder write it for you: a guided
config.json plus the deployment artefacts to carry
it — Compose, Kubernetes, systemd, launchd, or a plain binary.
It shows what each forgetting curve will actually keep, and
everything is generated in your browser.
The quickest path to a running instance. The service formula
installs a default embedded-SQLite config that survives
upgrades, plus a
brew services definition. The
hippocampus-cli (the hippo command)
and hippocampus-mcp (the Model Context Protocol
bridge) formulae are in the same tap.
brew install fastbean-au/tap/hippocampus
brew services start hippocampus
The published image is multi-arch (amd64 + arm64), so the same
tag works on a laptop, a VM, or a cluster node.
docker pull works identically.
podman pull ghcr.io/fastbean-au/hippocampus:latest
Every release publishes .deb and
.rpm packages carrying the binary, a hardened
systemd unit (DynamicUser, dropped capabilities,
ProtectSystem=strict), and a default config your
edits survive. Use rpm -i on RHEL, Fedora, or SUSE.
sudo dpkg -i hippocampus_<version>_amd64.deb
sudo systemctl enable --now hippocampus
Plain Kustomize — no Helm, no extra tooling. One overlay for the
embedded single instance (a StatefulSet and its
volume), one for the centralised model (a consolidator plus read
replicas over shared PostgreSQL).
kubectl apply -k deploy/k8s/overlays/sqlite
Ready-made stacks for each store — SQLite, PostgreSQL, MySQL, and OpenSearch (plain or secured) — plus a corporate-proxy variant, each with its config and a bundled Grafana dashboard.
docker compose -f deploy/compose/docker-compose.postgres.yaml up -d
The macOS counterpart to the systemd unit, for a personal
instance with no container runtime: it starts at login, restarts
on exit, and shuts down gracefully on
SIGTERM. Homebrew's
brew services wires this up for you.
launchctl bootstrap gui/"$(id -u)" ~/Library/LaunchAgents/au.fastbean.hippocampus.plist