Finite memory, done right

A memory engine that remembers what matters — for your logs, your audits, your agents, and more…

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.

Memory, modelled on the brain

Traditional stores lean on TTLs and FIFO queues, where age alone decides what survives. Hippocampus applies principles of human memory consolidation instead.

Relative significance

Insert events dynamically relative to their neighbours — ABOVE, BELOW, or BETWEEN — with no rigid, static importance scale to maintain.

Reinforcement through recall

Querying or accessing a record strengthens its retention weight, protecting high-demand operational data from decay.

Sleep & consolidation

Periodic background cycles apply decay models, compact space, and distil clusters of episodic detail into compact semantic summaries.

Durable & compliance-safe

Embedded or centralised, backed by SQLite, PostgreSQL, or MySQL — with minimum retention floors that hold regardless of storage pressure.

Pressure, not just age

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.

Nothing forgets silently

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.

Fits the stack you already run

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.

APIs & interfaces

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.

Storage backends

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.

Data ingestion

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.

Extend the core

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.

Integrations

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.

Deployment

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.

Operating it

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.

Runtime & security

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.

See it live

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.

agent & agent-flat

What significance buys you

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.

observer

An agent that decides what to keep

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 console
bluesky

Remember what people return to

Headlines 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 console
book

Summarise & forget

Great 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 console
grafana

Watch the telemetry

A 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

Get it

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.

config builder

Start with a configuration

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.

Open the config builder
homebrew

macOS & Linux

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 tap
container

Anywhere a container runs

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
The image
deb & rpm

Linux packages

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
The systemd unit
kubernetes

Kustomize overlays

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
The manifests
compose

Docker Compose

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 compose files
launchd

macOS LaunchAgent

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
The plist