Object Storage Vector Database: Where AIOZ Storage Fits

An object storage vector database keeps your vectors in the storage layer and searches them through an API, instead of running a cluster you size and pay for all day. This guide explains how that design differs from a dedicated vector database, where AIOZ Storage fits, and when you should pick something else.

TL;DR:

• An object storage vector database stores vectors like any other data and exposes similarity search through an API, so there is no cluster to provision.
• AIOZ Storage is in this family. It speaks the AWS S3 Vectors API and supports float32 vectors, a distance metric per index, metadata on each vector, and top-K queries.
• It suits large, long-lived collections that you query at a modest rate. It does not provide SQL, full-text search, or graph traversal, and AIOZ publishes no latency figures.
• For RAG, you embed chunks with your own model, store them with put_vectors, and fetch the closest ones with query_vectors before the language model answers.

Updated Oct 28, 2026: merged our separate post What Is Retrieval-Augmented Generation (RAG)? Explained into this guide.

What Is an Object Storage Vector Database?

A vector database stores embeddings and returns the ones closest in meaning to a query. If you want the background, our guide to the embedding model explains how text becomes vectors in the first place.

An object-storage-native vector database does this work inside the storage layer. Amazon's version is the S3 vector bucket, which AWS describes as a bucket type "purpose-built to store and query vectors" with "dedicated API operations." You group vectors into indexes, and AWS says each index "can be configured with specific dimensions, distance metrics (like cosine similarity), and metadata configurations."

A vector in this model has three parts: a key you choose that identifies it inside its index, a list of numbers, and optional metadata that describes it.

AIOZ Storage belongs to the same family, and its docs say it "works with the AWS S3 Vectors SDKs" and keeps vectors in the storage layer next to your other objects. So the tools you already use for S3 object storage still apply.

How Does It Differ From a Dedicated Vector Database?

Most dedicated vector databases run as a cluster or an instance that you provision, size, and pay for while it sits idle. An object-storage-native store works the other way around: vectors live in storage like any other data, and you reach them through an API. AIOZ's docs put it simply, saying there is "nothing to provision before your first write."

AIOZ's own comparison page lines the families up like this:

Storage also behaves differently from the text you started with, because a vector with 1,536 dimensions stored as float32 takes 6,144 bytes at 4 bytes per number. A paragraph of a kilobyte or so can therefore become a vector several times larger, and a big collection adds up quickly.

Cost follows the same split, since AIOZ's docs say provisioned services bill for capacity around the clock while usage-based ones bill for what you store and what you ask. We cover the actual charges in our guide to AIOZ Storage vector database pricing, so this post leaves the numbers there.

How You Use It in Four Calls

The workflow is short: create a vector bucket, create an index, put vectors, and query. This sample follows AIOZ's Python guide, with a three-number vector so it fits on screen. Real embeddings have hundreds or thousands of numbers, and the index dimension must match your embedding model.

import boto3

client = boto3.client(
    "s3vectors",
    region_name="us-east-1",
    aws_access_key_id="YOUR_ACCESS_KEY_ID",
    aws_secret_access_key="YOUR_SECRET_ACCESS_KEY",
    endpoint_url="https://s3.aiozstorage.network",
)

client.create_vector_bucket(vectorBucketName="my-vectors")

client.create_index(
    vectorBucketName="my-vectors",
    indexName="docs",
    dataType="float32",
    dimension=3,
    distanceMetric="cosine",
)

client.put_vectors(
    vectorBucketName="my-vectors",
    indexName="docs",
    vectors=[
        {
            "key": "doc-001",
            "data": {"float32": [0.12, 0.87, 0.45]},
            "metadata": {"title": "Intro", "source": "blog"},
        }
    ],
)

response = client.query_vectors(
    vectorBucketName="my-vectors",
    indexName="docs",
    queryVector={"float32": [0.11, 0.85, 0.47]},
    topK=5,
    returnMetadata=True,
    returnDistance=True,
)

We checked these calls with boto3's own parameter validation, capturing the requests without sending them. boto3 builds them as JSON POST requests to paths such as /CreateIndex, /PutVectors, and /QueryVectors on s3.aiozstorage.network, but we did not run them against a live AIOZ account.

AIOZ's MCP server docs list limits you should know about: an index dimension of up to 4,096, up to 500 vectors per put_vectors call, and a topK between 1 and 100. Check the SDK guides before you rely on those numbers outside the MCP server.

Using It as the Retrieval Step in RAG

Retrieval-augmented generation (RAG) is the workload AIOZ's comparison page names as this design's best fit, next to large, long-lived collections. AWS defines RAG as optimizing a language model's output "so it references an authoritative knowledge base outside of its training data sources before generating a response."

A model knows only what was in its training data. It has never seen your private documents or anything written after its cutoff, and when you ask about either, it may answer with confidence anyway. RAG fixes that by looking the facts up first. Luis Lastras, director of language technologies at IBM Research, puts it this way: "It's the difference between an open-book and a closed-book exam."

AIOZ's docs describe the flow in four steps, and each step maps to a call from the sample above:

1. Split your documents into chunks and run each chunk through an embedding model. You choose and run that model yourself, since put_vectors takes numbers, not text.
2. Store each vector with put_vectors, with the chunk's text or a reference to it in the metadata. The reference can be the key of the source file in an ordinary AIOZ Storage bucket.
3. When a user asks a question, embed it with the same model and call query_vectors with returnMetadata=True. The closest chunks come back with whatever text or reference you stored.
4. Pass those chunks to the language model as context, so its answer rests on your content instead of its memory.

The metadata also lets you cite sources. You know which chunk grounded each answer, so your app can link to it, and AWS lists source attribution among the ways RAG builds user trust. Keep metadata small, though, because the MCP server docs cap it at 40 KB and 50 keys per vector. Long chunks fit better as objects, with only their key stored next to the vector.

Updates are where RAG beats retraining. AWS calls RAG "a cost-effective approach" that works "without the need to retrain the model." When a document changes, you re-embed its chunks, delete the old ones by key with delete_vectors, and put the new vectors. When you delete a document, removing its vectors stops the model from citing it.

Where AIOZ Storage Fits

AIOZ's docs name five situations where this design works well:

• You already use S3-compatible tools and want vectors without a new database and a new query language.
• Your collection is large or growing, and you want storage-style economics instead of paying for a cluster around the clock.
• You retrieve for RAG, semantic search, or agent memory, where a well-ranked result matters more than the last few milliseconds. The RAG section above shows how that retrieval step works.
• You want embeddings on the same platform as the source files they came from.
• You need redundancy and availability without operating them yourself. AIOZ DePIN provides that by default through built-in erasure coding, which our guide to what AIOZ Storage erasure coding covers explains, including what it does not replace.

If you would rather not build the embedding step at all, Super Intelligence Memory lets an agent save plain-language statements with Record and ask questions with Recall. We compare the two routes in vector database vs agent memory on AIOZ Storage.

When to Choose Something Else

AIOZ says plainly that AIOZ Storage is not the best choice for every workload. It provides float32 vectors, a distance metric per index, metadata, and top-K similarity queries. It does not provide SQL, full-text search, or graph traversal, which leads to four cases:

• If you need single-digit-millisecond responses on every request, an in-memory database is built for that.
• If you want keyword search and vector search in the same query, a search engine cluster combines both.
• If your vectors must be joined with relational tables in one transaction, a relational database with a vector extension keeps them together.
• If your data is a knowledge graph and relationships matter as much as similarity, a graph engine fits better.

Zilliz, a vector database vendor, reviewed AWS's launch of S3 Vectors and drew a similar line. It found the design good for cold data and low query rates, and weak for sub-50 ms latency, frequent updates, and hybrid search. Those findings describe AWS's service, and Zilliz has its own product to sell.

For AIOZ Storage specifically, query latency and write throughput are unknown: the docs publish no figures. Test with your own vectors and your own query rate before you commit.

Can You Use Both?

Yes, and AIOZ's docs describe it as a common setup. A fast store holds the small set of vectors you search constantly, and AIOZ Storage holds the long tail. Your application checks the fast tier first and falls back to AIOZ Storage for everything else, so you pay for speed only where it changes the result.

The idea mirrors how you already treat files, and our guide to hot vs cold storage tiers explains when it pays to keep rarely used data on a slower, cheaper tier.

How to Test It Before You Commit

AIOZ's docs suggest four steps, and they work for any vector store:

1. Write down your requirements: how many vectors you will hold, the dimension of your embedding model, how often you will query, and how much response time matters to your users.
2. Run a small proof of concept. Create an account, generate access keys, create a vector bucket and an index, put a few hundred vectors, and query them.
3. Check the results against your content. Run real questions and see whether the closest matches are the ones a person would pick. If they are not, the embedding model or the chunking usually needs work before the database does.
4. Plan for production: how new content gets embedded and stored, how deleted content gets removed with DeleteVectors, and how you will monitor retrieval quality over time.

If an agent will work with the vector bucket directly, the MCP server lets an MCP-compatible assistant create buckets, indexes, and vectors for you.

Frequently Asked Questions

What is an object storage vector database?
It is a vector store that lives in the storage layer. You write vectors and metadata through an API and run similarity queries, so there is no cluster for you to size, patch, or run.

Is AIOZ Storage a vector database?
AIOZ's docs place it in the object-storage-native family, which keeps vectors in the storage layer and speaks the AWS S3 Vectors API. It is not a standalone database server that you operate.

Does AIOZ Storage support SQL or full-text search?
No. AIOZ's comparison page says it does not provide SQL, full-text search, or graph traversal, so you would pair it with another store when your queries need those features.

How fast are queries on AIOZ Storage?
AIOZ publishes no latency or throughput figures, so we cannot give you a number. Run a proof of concept with your own vectors, your own query rate, and the response time your users expect.

Do you have to create the embeddings yourself?
With the vector database you do, because you choose the embedding model and write the retrieval logic yourself. Super Intelligence Memory removes the embedding step for agent memory by letting you record and recall plain-language statements.

What is retrieval-augmented generation (RAG)?
RAG is a pattern where your app retrieves relevant passages from a knowledge base and hands them to a language model before it answers. On AIOZ Storage, the vector index holds that knowledge base, and query_vectors is the retrieval step.

Does RAG require retraining the model?
No. You update the knowledge base instead: re-embed the documents that changed and replace their vectors. AWS describes RAG as a cost-effective way to keep answers current without retraining.

Which SDKs work with it?
AIOZ provides step-by-step guides for Python, JavaScript, and Go, and its docs say the storage works with the AWS S3 Vectors SDKs. It also offers an MCP server so an MCP-compatible assistant can work with vector buckets directly.

Related Reading

• AIOZ Storage Vector Database Pricing: What You Pay For - the five charges and a worked example for the numbers this guide leaves out.
• Vector Database vs Agent Memory on AIOZ Storage: A Guide - when to manage vectors yourself and when to use Record and Recall.
• AIOZ Storage Super Intelligence Memory: Record and Recall - the two-call memory API that skips the embedding step.
• What Is an Embedding Model? How Text Becomes Vectors - where the vectors you store come from.
• What an MCP Server Is and How Agents Reach Storage - how an assistant reaches a vector bucket through one protocol.
• What AIOZ Storage Erasure Coding Covers and What It Doesn't - the built-in redundancy your vectors get on AIOZ DePIN.
• What Is S3 Object Storage? How It Works, Explained - the bucket, key, and API model that vector buckets build on.
• AIOZ Storage llms.txt docs for super intelligence - machine-readable docs that coding assistants can read before writing vector code.
• SI data pipelines on AIOZ Storage - where the vector index fits in a pipeline that keeps datasets and outputs in object storage.
• Offload LangGraph checkpoints to AIOZ Storage - keeping agent state in a bucket alongside your vectors.

References

• AIOZ Storage Docs: Vector Database, Options And Comparison
• AIOZ Storage Docs: Vector Database, Cost, Use Cases And Next Steps
• AIOZ Storage Docs: Vector Database
• AIOZ Storage Docs: Vectors And Vector Databases
• AIOZ Storage Docs: MCP Server
• AWS: What Is Retrieval-Augmented Generation?
• IBM Research: What Is Retrieval-Augmented Generation?
• AWS Documentation: What Is Amazon S3?
• AWS S3 API Reference: Welcome
• Zilliz: Will Amazon S3 Vectors Kill Vector Databases, or Save Them?