Amazon S3 Vectors vs. OpenSearch Serverless vs. pgvector for RAG: Cost Floors, Query Bills and Tenant Isolation

For two years the default answer to “where do the embeddings go” on AWS was OpenSearch Serverless, with pgvector on Aurora for teams that wanted everything in PostgreSQL. Both are good engines. Both also carried a monthly floor that made small and multi-tenant retrieval-augmented generation (RAG) workloads expensive before they served a single query.

Two releases changed that arithmetic. Amazon S3 Vectors became generally available in December 2025 with no compute to provision at all. Then, on 28 May 2026, AWS shipped a rebuilt OpenSearch Serverless that scales to zero when idle. Add Aurora Serverless v2’s automatic pause, and all three options can now cost close to nothing at rest. They get there by very different routes, and they isolate tenants in very different ways.

This article compares the three on the two questions that decide most designs: what the bill looks like at different workload shapes, and where the tenant boundary sits. The cost model is included and is checked against AWS’s own worked examples. The capacity estimates for OpenSearch and Aurora are marked as estimates.

Three stores, three billing models

How S3 Vectors charges for a query

S3 Vectors has no index to keep in memory, so there is no capacity unit. What it meters instead is the data a query has to process, and the definition is precise: the number of vectors in the index queried, multiplied by the average size of a vector, its key and its filterable metadata. Non-filterable metadata is excluded. The rate falls in three tiers, by position within the index: $0.004 per TB for the first 100,000 vectors, $0.002 per TB up to 10 million, and $0.0004 per TB beyond that.

Two consequences follow, and neither is obvious from the headline prices.

• Query cost grows with index size. A query against a 10-million-vector index processes forty times the data of a query against a 250,000-vector index. The same corpus split into many indexes is cheaper to query than one large index.
• Metadata placement is a pricing decision. The chunk text you return to the model belongs in non-filterable metadata. It is stored and returned, but it is not counted in the data processed by every query.

AWS’s own first pricing example makes the point without stating it. Ten million vectors, a million queries a month, $11.38. The example quietly assumes forty indexes of 250,000 vectors, one per customer. Put the same ten million vectors in a single index and the query-processing line alone rises from $3.37 to $97.26.

A cost model you can check

The S3 Vectors function below implements the billing rules exactly, using binary units as AWS does. The OpenSearch and Aurora functions are a different kind of thing: capacity estimates built on stated sizing assumptions, because their bills depend on how much memory the index needs.

"""vector_cost_model.py - monthly cost models, US East (N. Virginia)."""
from dataclasses import dataclass
from math import ceil

KIB, GIB, TIB = 1024, 1024**3, 1024**4
HOURS_PER_MONTH = 730


@dataclass(frozen=True)
class Workload:
    indexes: int                     # one per tenant in a siloed design; 1 for a pooled design
    vectors_per_index: int
    dimensions: int = 1024
    key_bytes: int = 174             # 0.17 KB, as in the AWS pricing examples
    filterable_bytes: int = 1024
    non_filterable_bytes: int = 1024
    queries_per_month: int = 1_000_000
    top_k: int = 10
    monthly_write_fraction: float = 1 / 6      # share of the corpus re-embedded each month
    active_hours: float = HOURS_PER_MONTH      # hours in which any query or write arrives

    @property
    def vectors(self) -> int:
        return self.indexes * self.vectors_per_index

    @property
    def vector_bytes(self) -> int:
        return 4 * self.dimensions             # float32

    @property
    def stored_bytes_per_vector(self) -> int:
        return self.vector_bytes + self.key_bytes + self.filterable_bytes + self.non_filterable_bytes


# ---------------------------------------------------------------- Amazon S3 Vectors (exact)
S3V_STORAGE_GB, S3V_PUT_GB, S3V_QUERY_PER_M, S3V_RETURN_GB = 0.06, 0.20, 2.50, 0.01
S3V_TIERS = ((100_000, 0.004), (9_900_000, 0.002), (float("inf"), 0.0004))    # vectors in tier, $ per TB
S3V_FREE_RETURN_BYTES, S3V_MIN_RESULT_BYTES = 500 * KIB, 256


def s3_vectors(w: Workload) -> dict[str, float]:
    stored_gb = w.vectors * w.stored_bytes_per_vector / GIB
    # Query processing is billed on the size of the index a query runs against, not on the corpus.
    processed = w.vector_bytes + w.key_bytes + w.filterable_bytes        # non-filterable metadata is excluded
    remaining, processing = w.vectors_per_index, 0.0
    for tier_vectors, per_tb in S3V_TIERS:
        in_tier = min(remaining, tier_vectors)
        processing += in_tier * processed * w.queries_per_month / TIB * per_tb
        remaining -= in_tier
        if remaining <= 0:
            break
    result_bytes = max(w.key_bytes + w.filterable_bytes + w.non_filterable_bytes, S3V_MIN_RESULT_BYTES)
    billable_return = max(w.top_k * result_bytes - S3V_FREE_RETURN_BYTES, 0)
    return {
        "storage": stored_gb * S3V_STORAGE_GB,
        "writes": stored_gb * w.monthly_write_fraction * S3V_PUT_GB,
        "query_processing": processing,
        "query_requests": w.queries_per_month / 1e6 * S3V_QUERY_PER_M,
        "data_returned": billable_return * w.queries_per_month / GIB * S3V_RETURN_GB,
    }


# ---------------------------------------------------------------- OpenSearch Serverless (estimate)
OCU_HOUR, OSS_STORAGE_GB, OCU_RAM_BYTES, HNSW_M = 0.24, 0.02, 6 * GIB, 16


def hnsw_memory_bytes(w: Workload) -> float:
    """OpenSearch sizing rule for full-precision HNSW: 1.1 * (4 * d + 8 * m) bytes per vector."""
    return 1.1 * (4 * w.dimensions + 8 * HNSW_M) * w.vectors


def _half_units(amount: float) -> float:
    """Capacity is granted in half units at the low end, whole units above that."""
    return 0.5 if amount <= 0.5 else float(ceil(amount))


def opensearch_serverless(w: Workload, *, next_gen: bool, standby: bool = True,
                          compression: float = 1.0) -> dict[str, float]:
    copies = 2 if standby else 1
    search_ocus = _half_units(hnsw_memory_bytes(w) / compression / OCU_RAM_BYTES) * copies
    indexing_ocus = 0.5 * copies
    # Classic bills its minimum around the clock. Next generation bills only hours with activity.
    hours = w.active_hours if next_gen else HOURS_PER_MONTH
    return {
        "compute": (search_ocus + indexing_ocus) * hours * OCU_HOUR,
        "storage": w.vectors * w.stored_bytes_per_vector / GIB * OSS_STORAGE_GB,
    }


# ---------------------------------------------------------------- Aurora Serverless v2 + pgvector (estimate)
ACU_HOUR, AURORA_STORAGE_GB, ACU_RAM_BYTES = 0.12, 0.10, 2 * GIB


def aurora_pgvector(w: Workload, *, auto_pause: bool, min_acu: float = 0.5,
                    compression: float = 1.0) -> dict[str, float]:
    index_bytes = w.vectors * (w.vector_bytes / compression + 8 * HNSW_M * 2)   # vectors plus graph links
    table_bytes = w.vectors * w.stored_bytes_per_vector
    acus = max(_half_units(index_bytes / ACU_RAM_BYTES), min_acu)        # keep the HNSW index in memory
    idle_hours = HOURS_PER_MONTH - w.active_hours
    idle_acu = 0 if auto_pause else min_acu
    return {
        "compute": (acus * w.active_hours + idle_acu * idle_hours) * ACU_HOUR,
        "storage": (index_bytes + table_bytes) / GIB * AURORA_STORAGE_GB,   # Aurora Standard; I/O charged separately
    }

Three workload shapes

All three scenarios use 1024-dimension vectors with about 2 KB of metadata each, a sixth of the corpus re-embedded every month, and ten results per query.

Three things stand out.

• At pilot scale the floor is the whole bill. A classic OpenSearch Serverless collection costs $350 a month to hold 100,000 vectors that S3 Vectors stores and serves for fourteen cents. Next-generation collections and a paused Aurora instance close most of that gap.
• At ten million vectors the memory is the bill. A full-precision HNSW index of this size needs about 43 GiB of memory. On the stated assumptions that is eight OCUs per copy or 21 ACUs, for as many hours as queries arrive. Scaling to zero helps only for the hours nobody is searching.
• S3 Vectors is the only store whose bill depends on how you partition. Scenarios B and C hold the same data and serve the same queries. Splitting by tenant cuts the S3 Vectors bill by a factor of nine and leaves the other two unchanged in this model.

What the low price gives up

S3 Vectors is cheap because it is an object store with a vector index, not a search engine or a database. The trade is explicit.

For a chat assistant, where the language model takes seconds to answer, 100 ms of retrieval is invisible. For search-as-you-type, or a pipeline that issues dozens of retrievals per request, it is not. And if relevance depends on exact terms such as product codes, drug names or error identifiers, the absence of keyword search matters more than any latency figure.

Where the tenant boundary sits

Cost and isolation turn out to be the same decision in two of the three stores.

S3 Vectors: one index per tenant. An index has its own ARN, so IAM can grant a principal access to exactly one tenant’s vectors, and a bucket holds up to 10,000 indexes. Because query cost follows index size, the siloed design is also the cheap one. The application never passes a tenant filter. It addresses a different index.

"""s3vectors_tenant.py - one vector index per tenant inside one vector bucket (excerpt)."""
import re
from typing import Any

import boto3
from botocore.config import Config

BUCKET = "rag-vectors-prod"
TENANT_ID = re.compile(r"[a-z0-9][a-z0-9-]{1,40}")

_client = boto3.client(
    "s3vectors",
    config=Config(retries={"max_attempts": 8, "mode": "adaptive"}, connect_timeout=3, read_timeout=10),
)


def index_name(tenant_id: str) -> str:
    """The tenant id comes from the caller's verified identity, never from request text."""
    if not TENANT_ID.fullmatch(tenant_id):
        raise ValueError("invalid tenant id")
    return f"tenant-{tenant_id}"


def search(tenant_id: str, embedding: list[float], top_k: int = 8,
           doc_id: str | None = None, client: Any = _client) -> list[dict]:
    request: dict[str, Any] = {
        "vectorBucketName": BUCKET,
        "indexName": index_name(tenant_id),
        "queryVector": {"float32": embedding},
        "topK": top_k,
        "returnMetadata": True,       # needs s3vectors:GetVectors as well as s3vectors:QueryVectors
        "returnDistance": True,
    }
    if doc_id:
        request["filter"] = {"doc_id": {"$eq": doc_id}}
    return client.query_vectors(**request)["vectors"]


def tenant_policy(account_id: str, region: str) -> dict:
    """Attach to the role the application assumes with a TenantId session tag.
    One policy serves every tenant. Verify the tag substitution in your account before relying on it."""
    return {
        "Version": "2012-10-17",
        "Statement": [{
            "Effect": "Allow",
            "Action": ["s3vectors:QueryVectors", "s3vectors:GetVectors", "s3vectors:PutVectors",
                       "s3vectors:DeleteVectors"],
            "Resource": f"arn:aws:s3vectors:{region}:{account_id}:bucket/{BUCKET}"
                        "/index/tenant-${aws:PrincipalTag/TenantId}",
        }],
    }

%%{init: {'theme':'base','themeVariables':{'actorBkg':'#FFF3E0','actorBorder':'#FF9900','actorTextColor':'#232F3E','signalColor':'#0073BB','signalTextColor':'#0F172A','noteBkgColor':'#FFF8E7','noteBorderColor':'#FF9900','noteTextColor':'#232F3E','labelBoxBkgColor':'#FFF3E0','labelBoxBorderColor':'#FF9900','labelTextColor':'#232F3E','loopTextColor':'#232F3E','activationBkgColor':'#EBF8FF','activationBorderColor':'#0073BB','lineColor':'#232F3E','textColor':'#232F3E'}}}%%
sequenceDiagram
    participant A as RAG service
    participant T as AWS STS
    participant V as S3 Vectors
    participant M as Bedrock model
    A->>T: AssumeRole, session tag TenantId=acme
    T-->>A: Credentials scoped by tag
    A->>V: QueryVectors on index tenant-acme
    V-->>A: Top matches + chunk text
    A->>M: Prompt with retrieved context
    M-->>A: Answer
    Note over A,V: A request for tenant-globex
is denied by IAM, not by app code

OpenSearch Serverless: one collection per tenant. Under classic pricing this was unaffordable beyond a handful of tenants, because every collection carried the minimum. On next-generation collection groups an idle tenant costs storage only, and data access policies with wildcard patterns keep the policy count manageable. The price is a cold start: AWS describes the first request after scaling to zero as taking about 10 seconds. Setting a minimum above zero removes the wait and restores a floor.

Aurora pgvector: row-level security. The natural model in PostgreSQL is one table with a tenant column and a policy the database enforces on every statement.

-- pgvector_rls.sql - pooled multi-tenancy: one table, row-level security.
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
    id         bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    tenant_id  text        NOT NULL,
    doc_id     text        NOT NULL,
    content    text        NOT NULL,
    embedding  vector(1024) NOT NULL
);

CREATE INDEX chunks_tenant_idx ON chunks (tenant_id);
CREATE INDEX chunks_embedding_idx ON chunks USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- Every query is filtered by the tenant held in the session, whatever SQL the application sends.
ALTER TABLE chunks ENABLE ROW LEVEL SECURITY;
ALTER TABLE chunks FORCE ROW LEVEL SECURITY;          -- applies to the table owner as well

CREATE POLICY tenant_isolation ON chunks
    USING      (tenant_id = current_setting('app.tenant_id', true))
    WITH CHECK (tenant_id = current_setting('app.tenant_id', true));

-- The application connects as a role that cannot bypass the policy.
CREATE ROLE rag_app NOLOGIN NOBYPASSRLS;
GRANT SELECT, INSERT, DELETE ON chunks TO rag_app;

The application sets the tenant inside each transaction with SELECT set_config('app.tenant_id', $1, true), so the value cannot leak to the next user of a pooled connection. In the test, each tenant’s similarity search returned only its own rows, a session with no tenant set returned nothing, and an insert carrying another tenant’s id was rejected.

Choosing between them

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FFF3E0','primaryTextColor':'#232F3E','primaryBorderColor':'#FF9900','lineColor':'#232F3E','clusterBkg':'#F8FAFC','clusterBorder':'#CBD5E1','edgeLabelBackground':'#FFFFFF','nodeTextColor':'#232F3E'}}}%%
flowchart TD
    Q1{Need keyword or hybrid search,
or retrieval in single-digit ms?}
    Q1 -- "Yes" --> OS[OpenSearch Serverless
next generation]
    Q1 -- "No" --> Q2{Must vectors change in the same
transaction as business rows?}
    Q2 -- "Yes" --> PG[Aurora PostgreSQL
with pgvector]
    Q2 -- "No" --> Q3{Many tenants, or queries
that arrive in bursts?}
    Q3 -- "Yes" --> S3[S3 Vectors
one index per tenant]
    Q3 -- "No" --> Q4{Already run Aurora
with spare capacity?}
    Q4 -- "Yes" --> PG
    Q4 -- "No" --> S3
    class Q1,Q2,Q3,Q4 edge
    class OS mesh
    class PG compute
    class S3 store
classDef compute fill:#FFF3E0,stroke:#FF9900,stroke-width:2px,color:#232F3E
classDef edge fill:#EBF8FF,stroke:#0073BB,stroke-width:2px,color:#004C74
classDef store fill:#F0FFF4,stroke:#1D8102,stroke-width:2px,color:#145202
classDef alert fill:#FEF2F2,stroke:#D13212,stroke-width:2px,color:#991B1B
classDef mesh fill:#F3E8FF,stroke:#7C3AED,stroke-width:2px,color:#4C1D95

• Start with S3 Vectors for document question-answering, internal assistants and multi-tenant SaaS where a retrieval takes place once per user turn. The cost floor is zero and the isolation model is IAM.
• Choose OpenSearch Serverless when relevance needs lexical matching alongside vectors, when latency budgets are tight, or when the same engine already serves search. Use next-generation collections for anything new.
• Choose pgvector when embeddings are an attribute of rows you already keep in PostgreSQL and must stay consistent with them, or when retrieval needs joins and predicates that metadata filters cannot express.
• Combine them when the corpus has a hot head and a long tail. The S3 Vectors announcement describes OpenSearch managing vector storage in S3 for exactly this split.

Running it in production

• Batch writes to S3 Vectors. A PutVectors call accepts up to 500 vectors and each call carries a minimum charge. Single-vector writes multiply the upload bill.
• Plan for the first query. All three scale-to-zero options answer the first request slowly: under a second, about 10 seconds, or up to 15 seconds. Decide per workload whether to keep capacity warm, and set client timeouts above the resume time.
• Know what blocks an Aurora pause. Open connections, RDS Proxy and logical replication all keep the instance awake. A connection pool that never closes its connections quietly turns automatic pause into a 0.5 ACU floor.
• Tag by tenant. Per-tenant indexes and collections make cost attribution possible. Without tags the bill is one line.
• Keep the embedding model in the index name or metadata. Re-embedding with a new model means a new index. Dual-write and cut over per tenant.
• Measure recall with your own questions. Approximate search, filters and quantisation all trade recall for cost. Keep a fixed evaluation set per tenant and run it whenever the configuration changes.

Key takeaways

• By mid-2026 all three AWS vector stores can cost near zero at rest. They differ in what happens once queries arrive.
• S3 Vectors bills each query on the size of the index it touches. One index per tenant is both the isolation model and the cheapest layout.
• For OpenSearch Serverless and Aurora, memory to hold the index is the dominant cost at scale. Quantisation is the main lever.
• Classic OpenSearch Serverless collections still carry a two-OCU minimum. New work belongs on next-generation collections.
• Choose on capability first: hybrid search and latency point to OpenSearch, transactional consistency to pgvector, and everything else to S3 Vectors.

If you have production bills for any of these three at ten million vectors or more, I would like to compare them with the estimates here. Leave a comment below.

Glossary

RAG (retrieval-augmented generation)

Fetching relevant passages from a store and adding them to a model prompt so that answers are grounded in your own data.

Embedding

A list of numbers representing the meaning of a piece of text. Similar texts have nearby embeddings.

Vector index

A structure that finds the nearest embeddings to a query without comparing against every stored vector.

HNSW

Hierarchical Navigable Small World. A graph-based approximate nearest-neighbour index, fast when held in memory.

Quantisation

Storing vectors at lower precision to save memory, at some cost in recall.

Recall

The share of the true nearest neighbours that an approximate search returns.

OCU (OpenSearch Compute Unit)

The capacity unit OpenSearch Serverless bills by the hour for indexing and search.

ACU (Aurora Capacity Unit)

The capacity unit Aurora Serverless v2 bills by the hour, roughly 2 GiB of memory with matching CPU.

Vector bucket

The S3 Vectors container that holds vector indexes.

Filterable metadata

Key-value data stored with a vector that queries can filter on. In S3 Vectors it counts towards query data processed.

Siloed and pooled tenancy

Siloed gives each tenant its own resource. Pooled shares one resource and separates tenants by policy or filter.

Row-level security

A PostgreSQL feature that applies a policy to every query on a table, restricting which rows a session can see or change.

Hybrid search

Combining keyword matching and vector similarity in one ranked result.

References & Further Reading

• → Amazon S3 pricing: S3 Vectors — Rates, tier definitions and the worked examples the model is checked against
• → S3 Vectors: limitations and restrictions — Indexes per bucket, vectors per index, metadata and batch limits
• → S3 Vectors: access management — IAM actions and the index ARN format used for per-tenant policies
• → Amazon S3 Vectors is now generally available — Scale, latency and integration statements from 2 December 2025
• → Amazon OpenSearch Service pricing — Serverless OCU minimums and the scale-to-zero behaviour of next-generation collections
• → Introducing the next generation of Amazon OpenSearch Serverless — The 28 May 2026 announcement
• → Multi-tenant search with OpenSearch Serverless next generation — Collection per tenant, wildcard policies and cold-start figures
• → Amazon Aurora pricing — ACU, storage and I/O rates
• → Scaling to 0 capacity with Aurora Serverless v2 — Automatic pause, resume time and what prevents pausing
• → pgvector 0.8.0 on Aurora PostgreSQL — Iterative index scans for filtered queries
• → pgvector on GitHub — Index types, dimension limits and query settings