Getting Started
How It Compares
Choose MemorySync when your application needs durable, semantically retrievable context with explicit project and end-user scope. The right choice depends on the data and control your product needs.
Compare the common approaches
| Approach | Best for | You manage |
|---|---|---|
| Prompt-only context | Information needed during one request or short conversation. | Prompt selection and token limits. |
| Application database | Exact records, transactions, and authoritative business data. | Schema, queries, and relevance logic. |
| Self-managed vector retrieval | Teams that want full control of a custom retrieval stack. | Ingestion, embeddings, indexing, scope, lifecycle, and operations. |
| MemorySync | Persistent application context retrieved by meaning and isolated by project and end user. | What to write, when to query, and how results enter the model prompt. |
When MemorySync is a strong fit
- User preferences or prior outcomes should improve later sessions.
- Your application needs semantic retrieval rather than exact-key lookup alone.
- One server-side credential represents many end users that must remain separated.
- You want memory APIs and lifecycle controls without operating a retrieval service yourself.
When another system should remain primary
- Use your application database for balances, permissions, orders, and other source-of-truth records.
- Use the current model context for instructions that should not persist.
- Keep document ownership and authorization in the source system.
- Use your model provider for generation; MemorySync supplies context, not the final answer.
Evaluate with representative tasks
- 1Select real questions from your product and define the facts each answer should use.
- 2Write only those facts, preserving useful source and metadata fields.
- 3Query with realistic wording and inspect relevance, scope, and deletion behavior.
- 4Measure end-to-end quality, latency, and usage in your own application before production.
Continue
Was this page helpful?