What is Device Memory?
In the standard Nebula model, your memory graph lives on Nebula’s servers. Device Memory inverts this: your application owns the canonical graph state, and Nebula operates as a stateless compute engine.
Your app stores a portable snapshot locally — on-device, in your database, wherever you choose. When new content arrives, you send it to Nebula. Nebula processes the content and returns a patch describing what changed. Your app applies the patch locally and moves on.
Nebula never persists your data. Any server-side state is ephemeral and cleaned up immediately after each request.
When to Use Device Memory
- Privacy — user data stays on-device or in your own infrastructure
- Offline-first — local memory graph that syncs when connectivity is available
- Portability — the snapshot is a self-contained file you can move anywhere
- Edge deployments — no server-side state to manage
If you’re fine with Nebula managing your state, the standard hosted API is simpler. See the
Quick Start.
How It Works
1. Bootstrap — Download an initial snapshot from an existing Nebula collection. After this, your local copy is canonical.
2. Ingest — Send new events to Nebula. It processes them and returns a patch. The SDK applies the patch to your local snapshot automatically.
3. Search — Query your memory through Nebula’s traversal engine. Your snapshot is sent, scored, and results are returned. Nothing is stored server-side.
4. Export / Import — Serialize the snapshot to portable bytes for backup or transfer between devices.
Limitations
Device Memory is a single-writer protocol. If multiple devices mutate the same collection concurrently, patches will conflict. Use one writer at a time.
Next Steps
