Vector Database vs Agent Memory on AIOZ Storage: A Guide

The vector database vs agent memory question usually gets answered with a diagram of a cognitive architecture: retrieval at the bottom, consolidation and scoring on top. AIOZ Storage offers both names as real features, and they are closer together than that diagram suggests. This guide compares them on what AIOZ's documentation actually says each one does, so you can pick based on the calls you will write, not on the labels.

TL;DR:

• Use the AIOZ Storage Vector Database when you want to choose the embedding model, set the dimension and distance metric, attach metadata, and manage vectors by key.
• Use Super Intelligence Memory when an agent just needs to save short statements and find them later by meaning, with no embeddings or index to manage.
• Memory runs on the vector database, in a dedicated memory-managed bucket, and adds $0.00005 per Record or Recall call on top of the vector rates.
• The documented Memory API is deliberately small: no metadata, filters, namespaces, or user scoping, so de-duplication and stale-fact handling stay in your application.

Which One Should You Use?

Use the vector database if you need control: your own embedding model, your own metadata, filtering, or deleting individual vectors. Use Memory if you want an agent to remember short statements with two calls and nothing to configure. They are not rivals. Memory is built on top of the vector database, and AIOZ's own documentation lists both as ways to give an agent memory.

What Each One Is

AIOZ's Vector Database exposes the AWS S3 Vectors API: a vector bucket holds indexes, each index fixes a dimension and a distance metric, and each vector is a key, a list of numbers, and optional metadata. You generate the embeddings yourself and send them in.

Super Intelligence Memory is a higher-level API on a special kind of bucket, one created with memoryManaged set to true. You call Record with a plain-language statement, and later call Recall with a plain-language question. AIOZ handles the embedding.

What "Agent Memory" Usually Means, and Where Memory Sits

Industry guides draw a sharp line between the two. Atlan's architecture guide puts it this way: "A vector database answers 'what is similar?' An agent memory system answers 'what does this agent know, and is it still true?'" In that framing, a memory system manages what gets stored, consolidated, scored, and discarded across sessions.

AIOZ's Memory is more modest, and it helps to be exact about it. The documented behavior is storage and retrieval by meaning:

• Every successful Record creates a new memory with a new memoryId. Send the same statement twice and it is stored twice.
• Recall ranks saved statements from most to least similar, and it does not filter out weak matches. If the bucket has any memories, you get back up to limit results, even when none answers the question.
• The docs describe no consolidation, scoring, expiry, metadata, or user scoping.

That is retrieval with the embedding step handled for you. It does not decide what is still true, so if your agent needs to drop outdated facts or merge duplicates, that logic belongs in your code.

Choose the Vector Database When

• You are building retrieval over documents. Chunks, titles, source URLs, and document IDs belong in metadata, and AIOZ's docs list retrieval-augmented generation and keeping embeddings next to source files among the cases where the vector database fits well.
• You need a specific embedding model. The index dimension has to match your model's output (AIOZ's examples use 1536), and you pick the distance metric once per index.
• You need to manage individual vectors. Vectors have keys, so you can fetch, list, and delete them by key.
• You want the MCP route. AIOZ's MCP server exposes bucket, index, and vector operations, so a super intelligence assistant can work with vector buckets directly.

Choose Memory When

• The agent saves short facts as it works: a user preference, a decision, a note about a customer: one sentence per Record.
• You do not want an embedding pipeline. Memory generates embeddings automatically, with no index to design.
• Plain-language recall is enough. Recall takes a question and returns ranked statements with a similarity score, and optionally the cosine distance.

What to Plan For With Memory

Memory's simplicity moves a few jobs to you. The docs give three behaviors worth designing around:

1. Retries need care. The SDKs do not retry Record automatically. After a network error or timeout, check whether the memory was saved before you try again, or you may store it twice.
2. Recall always answers. Because weak matches are not filtered, check the similarity score and set your own cutoff before you pass results to a model.
3. Separation is your design. Recall works across one whole bucket, and no namespaces or user scoping are documented, so keeping one user's memories apart from another's is something you have to plan for.

Errors are straightforward: a 400 ValidationException for a non-memory-managed bucket, empty or oversized text, or a limit outside 1 to 100; a 403 for credential or signature problems; and a 503 ServiceUnavailableException when the embedding service is temporarily down.

Can You Use Both?

Yes, and they combine naturally because they share a foundation. A memory-managed bucket can hold what the agent learns, while a regular vector bucket holds the knowledge base the agent searches. Both use the same AWS Signature Version 4 authentication, and Memory's charges are the vector database's plus the per-call memory fee.

On cost, the difference is easy to work out. A million Record calls and a million Recall calls add 2 million memory fees, which at $0.00005 each is $100, before the usual storage ($0.05 per GB-month), upload ($0.04 per GB), and query ($0.000002 per query) charges that both options share.

Frequently Asked Questions

What is the difference between a vector database and agent memory?
A vector database stores embeddings and returns the closest matches. Agent memory, in the broad industry sense, adds logic for what to keep, update, and discard across sessions. On AIOZ Storage, Memory is a simple Record and Recall layer built on the vector database.

Does AIOZ Super Intelligence Memory replace the vector database?
No. It runs on top of it, using a memory-managed vector bucket, and it covers only the save-and-recall case. The vector database remains the choice for document retrieval, metadata, and custom embeddings.

Do I need to create embeddings for Memory?
No. AIOZ states that you do not create embeddings, vector indexes, or vectors yourself when you use Memory. With the vector database, you send vectors you computed yourself.

Can I use metadata filters with Super Intelligence Memory?
The documentation describes no metadata, filters, namespaces, or user scoping for Memory. If you need filtering, use the vector database, which stores metadata with each vector.

Why does Recall return results even when nothing matches?
Recall does not filter weak matches. It returns up to limit results whenever the bucket has any memories, so check each result's similarity score before trusting it.

Can I run both in the same account?
Yes. Use a memory-managed bucket for agent memory and a regular vector bucket for document retrieval. Regular put and delete calls are rejected on memory-managed buckets, so the two bucket types stay separate.

Related Reading

• AIOZ Storage Super Intelligence Memory: Record and Recall - the full Record and Recall API, errors, and SDKs.
• AIOZ Storage Docs: Vector Database - the docs overview of vector storage on AIOZ Storage, with links to the SDK guides.
• What Is Retrieval-Augmented Generation (RAG)? - the main use case for a regular vector bucket.
• What Is an Embedding Model? - why the dimension and model choice matter for an index.

References

• AIOZ Storage Docs: Super Intelligence Memory
• AIOZ Storage Docs: Vector Database Cost, Use Cases and Next Steps
• AIOZ Storage Docs: Vector Database Options and Comparison
• Atlan: Agentic Memory vs Vector Database