What “self-hosted memory” actually means
Self-hosting a memory layer is not only running a container. It means owning the database that stores the memories, the vector index that supports retrieval, the backups that protect both, and the deletion path that proves a user’s data is gone.
The application contract should stay the same. Your agent should call the same add and search operations whether the memory service runs in a managed cloud, in your VPC or on a machine you operate.
- Your event data and derived memories stay in infrastructure you control.
- Your retention policy and deletion process apply to the memory store directly.
- Your backup, restore and disaster recovery procedures cover the memory graph.
- Your team owns upgrades, capacity planning and latency tuning.
The deployment options to compare
| Option | What you own | Best for |
|---|---|---|
| Managed service | Account, scopes and memory content; the provider runs the store. | Teams that want the fastest path to production. |
| Your VPC | Network boundary, database and access controls inside your cloud account. | Teams with strict network or data residency rules. |
| Self-hosted | The runtime, database, vector index, backups and upgrades. | Teams that cannot use a shared control plane at all. |
| Bring your own vector store | The vector index and its capacity; the memory API sits beside it. | Teams that already operate a vector database. |
The exact packaging depends on the current AI Memory plan and deployment options. Confirm the supported path with support before you design around a specific topology.
Data residency is a workflow, not a checkbox
A data residency promise is only credible if the data path matches it. Ask where the event is processed, where the derived memory is stored, where the vector index lives, where backups are written and which support staff can access the system.
For a memory layer, the derived memory can be more sensitive than the raw event because it contains conclusions. A support note that says “the customer is likely to churn” is a different artifact from the transcript that produced it.
- Map the full path: ingest, extraction, storage, retrieval, backup and deletion.
- Decide whether derived memories may leave the region even if raw events do not.
- Log who can read or export the graph, not only who can write to it.
- Test deletion end to end, including backups and derived summaries.
The tradeoffs nobody puts on the pricing page
Self-hosting can be cheaper at scale and more expensive at small scale. The break-even point depends on the engineering time you spend on backups, upgrades, monitoring and incident response, not only on the infrastructure bill.
| Tradeoff | What it looks like in practice | How to mitigate it |
|---|---|---|
| Operational load | Upgrades and schema changes become your release process. | Pin versions, stage upgrades and keep a rollback image. |
| Backups | A memory graph without a restore test is not backed up. | Run a restore drill before production traffic. |
| Latency | A remote vector store changes p50 and p95 retrieval. | Measure from the same region as the application. |
| Capacity | Memory grows faster than request volume in long-lived accounts. | Set retention and compression budgets early. |
| Compliance | Deletion must reach derived memories and backups. | Document the path and test it with a real user id. |
Portability is the point of a self-hosted path
The strongest reason to self-host is not cost. It is the ability to leave. A memory layer should export the graph with source, scope, timestamps and versions, and the export should be readable without the vendor’s application.
AI Memory treats JSON export as a first-class operation. If your team later moves to another store or another cloud, the graph should move with you.
{
"memory": "Northwind renewed on the Scale plan, billed annually.",
"kind": "decision",
"scope": { "tenant": "northwind", "user": "dana" },
"source": "billing events",
"created_at": "2026-10-09T08:12:00Z",
"supersedes": "mem_01H...",
"version": 3
}A self-hosting checklist
- Choose the smallest topology that satisfies your data boundary.
- Test the restore path before you test the happy path.
- Measure retrieval from the same region as the application.
- Set a retention policy for episodes, facts and audit history separately.
- Prove deletion with a test user and a derived memory.
- Keep a vendor-neutral export and a copy of the schema.
Frequently asked questions
Can I self-host AI Memory today?
AI Memory publishes a self-hosted path for the same API. Confirm the current deployment options and plan requirements with support before you commit to a specific environment.
Can I bring my own Postgres database?
The self-hosted path is designed to run against your own database and storage. The exact supported topology should be confirmed against the current deployment documentation.
Does self-hosting remove the need for data deletion controls?
No. Self-hosting moves the responsibility to you. You still need deletion by user or tenant, retention windows and an audit trail that covers derived memories and backups.
Is self-hosting cheaper?
It can be cheaper at scale, but the break-even point depends on engineering time, backups, upgrades and incident response. Calculate the total cost, not only the infrastructure bill.
Can I move from managed to self-hosted later?
That is the purpose of a portable graph. Export the JSON, replay it into the self-hosted deployment, and compare search results before cutting over reads.
What about latency?
Latency depends on where the application, database and vector index run. Measure p50 and p95 from the same region as the application, and include the reranking step in the measurement.