# Pinecone vs Amazon S3 Vectors

> Pinecone wins once queries are sustained, because its Dedicated Read Nodes turn read cost into a flat monthly figure while S3 Vectors keeps pricing every query against the size of the whole index. S3 Vectors is the better choice for a large corpus queried rarely, where paying nothing while idle matters more than the cost of each query.

Source: https://www.pinecone.io/compare/s3-vectors/
Claims about S3 Vectors last checked against its documentation on 2026-09-08.

## Summary

Most of the difference between these two comes down to what each one charges for. S3 Vectors charges per query, based on the size of the index being queried. Pinecone charges for the reads you perform. On Dedicated Read Nodes, that per-read charge becomes a fixed monthly rate for provisioned capacity.

As a result, the two cost lines cross at some query rate. Below it, S3 Vectors is cheaper, often by a wide margin, because an idle index costs only storage. Above it, a data processing charge computed from the whole index on every query adds up to more than the flat monthly rate for provisioned capacity. Where the crossover sits depends on your corpus size and query rate. Both vendors publish the list prices you need to work it out.

Beyond price, the two differ in what you can tune, what you have to decide when you create an index, and where each service's limits sit. A cost spreadsheet will not show you any of these.

## Choose Pinecone when

- Query volume is sustained and you need read cost you can predict.
- You want something you can adjust. S3 Vectors has no tuning parameter for queries.
- Your corpus changes constantly and you do not want deleted vectors billed as part of the index for up to a day.
- You need more than 4,096 dimensions.
- Retrieval has to run somewhere other than AWS.

## Choose S3 Vectors when

- The corpus is large and queried rarely. S3 Vectors was built for this workload and is a strong choice for it.
- Paying only for storage while nobody is querying matters more than per-query cost. An archive searched a few times a day is a typical example.
- You are committed to AWS and want retrieval to stay inside the same account, IAM policies, and bill.
- You already use the OpenSearch integration to move vectors between S3 Vectors and OpenSearch.

## Feature by feature

| Capability | Pinecone | S3 Vectors |
| --- | --- | --- |
| Deployment model | You create an index and write to it. Data sits in object storage, Pinecone runs the servers that answer queries, and you never choose an instance size, a node count, or a cluster layout. | A vector bucket and an index inside it. There are no nodes, replicas, or cache tier to choose and nothing to provision. |
| Scaling model | Automatic on the on-demand tier, where you never pick a shard or replica count. On Dedicated Read Nodes, which are capacity you provision, shards and replicas are set by hand today. | Storage scales on its own. There is no compute to scale. That also means you have nothing to add when queries get slower or more expensive. |
| Pricing model | Reads and writes you perform, plus storage. Dedicated Read Nodes replace per-query read cost with a fixed monthly rate. | A per-query request fee, a charge for data processed, and a charge for data returned, plus storage and uploads. Data processed is the average vector size multiplied by the number of vectors in the index. The per-terabyte rate drops above 100,000 vectors and again above 10 million. |
| Tuning the query | You choose a read capacity tier. Pinecone handles indexing and quantization as it re-optimizes the index in the background. | No tuning parameters for queries. Recall and latency are whatever the service delivers. |
| Changing the index later | Dimension and metric are also fixed at creation. Pinecone revises indexing and quantization in the background as it re-optimizes the index. You do not have to rebuild it. | Dimension, distance metric, and which metadata keys are non-filterable are all set at creation and cannot change afterward. |
| Embedding dimensions | Up to 20,000 dimensions for dense vectors. | 1 to 4,096. |
| Multi-tenancy | One index holds a namespace per tenant, with nothing to provision for each new tenant. The documented limit is 100,000 namespaces per index on Standard and 1,000,000 on Enterprise. Dedicated Read Nodes support one namespace per index today. For now you cannot combine them with a design that keeps many tenants in one index. | One index per tenant, with up to 10,000 indexes per vector bucket and 10,000 buckets per region per account. Each tenant gets a fully isolated index instead of a namespace inside a shared one. |
| Running it in your own cloud | Bring your own cloud on AWS, Azure, and GCP. | No equivalent. S3 Vectors runs in your AWS account and only on AWS. |

## S3 Vectors by the numbers

These figures come from AWS's own documentation. They decide whether the pricing model above works in your favor.

- **2 billion** vectors per index, with up to 10,000 indexes per bucket and 10,000 buckets per region
- **4,096** maximum dimensions per vector, at 4 bytes per dimension
- **1,000/s** combined write and delete requests per index, with a separate limit of 2,500 vectors per second
- **up to a day** that deleted or overwritten vectors keep counting toward index storage and therefore toward query cost

## Each query is priced by the size of the whole index

How S3 Vectors bills a query explains most of the cost difference. AWS calculates the data processed charge from the average vector size (including vector data, key, and metadata) multiplied by the number of vectors in the index you are querying.

The charge is unrelated to the work a query does. A query for the top 10 results and a query for the top 1,000 process the same amount of billable data when they run against the same index. Adding vectors to an index raises the price of every query against it, including queries that would never have touched the new vectors.

AWS lowers the per-terabyte rate above 100,000 vectors and again above 10 million. It also leaves non-filterable metadata out of the calculation. Even with those discounts, the cost of each query still grows with the size of the corpus.

Pinecone charges for the reads you perform. Dedicated Read Nodes go further and replace per-query cost with a fixed monthly rate for provisioned capacity. You pay a fixed amount, as you would for a search cluster, without running one. Somewhere between occasional and sustained querying, the two cost lines cross. Both vendors publish list prices. Use them to find the crossover for your own corpus size and query rate. Do not take that number from either of us.

## Deleted vectors keep costing you until they are reclaimed

The AWS pricing page describes a side effect of this model. When you overwrite or delete a vector, AWS removes it from query results immediately, but reclaiming its storage can take up to a day. Until then, the vector still counts toward the index size.

Because query cost is computed from index size, a workload that frequently rewrites the same keys pays query charges on vectors it has already deleted. AWS notes that such workloads can temporarily see higher query costs.

How much this matters depends on your write pattern. It is a property of the pricing, not a defect. A corpus loaded once and read for months will never notice. A pipeline that re-embeds and rewrites documents every night pays for yesterday's copies while serving today's.

Pinecone rewrites its storage files in the background too, but it does not bill queries against deleted records that are still waiting to be reclaimed. Pinecone's write pricing has a cost detail of its own. Upserts (writes that insert or overwrite a record) bill a minimum of five write units per request. Streaming single vectors therefore costs more per vector than batching them. Both services reward batching.

## S3 Vectors has no query settings to tune

S3 Vectors has no tuning parameter for queries. You cannot raise ef_search (the setting that controls how widely an HNSW graph index searches), choose how many index partitions to probe, oversample candidates, or set how many results get reranked. You send a query and take what the service returns.

This is a deliberate trade. Because there is nothing to tune, S3 Vectors has no compute tier to size, no cluster to plan, and no capacity decision on day one. For a great many workloads that is the right trade. Pinecone does not let you choose an index type for the same reason.

The difference shows up when the defaults are not good enough. On Pinecone, you can move to a different read capacity tier. Pinecone also revises indexing and quantization automatically in the background as the data grows. On S3 Vectors, you cannot change how queries run. Your remaining option is architectural. AWS documents an integration that exports vectors into OpenSearch for workloads that need low-latency or tunable search. Using it means running the second system you were trying to avoid.

Neither vendor publishes figures showing how recall holds up as a filter matches a smaller share of the index. If filtered recall decides the choice for your workload, test both services with your own filters and data. Do not rely on either vendor's description of its own filtering.

## What you cannot change after creating an index

In S3 Vectors, dimension, distance metric, and the list of non-filterable metadata keys are set when the index is created. None of them can change afterward. Changing any of them means creating a new index and reloading it.

A Pinecone index also fixes dimension and metric at creation. On those two settings the services are the same. Plan the non-filterable keys carefully. You pick them at the start, when a wrong pick is easy to make and expensive to discover later. The choice also affects cost. Non-filterable metadata is left out of the data processed charge. Marking a key non-filterable therefore changes both what you can filter on and what each query costs. It does save money, but an index can declare at most ten non-filterable keys.

Check the 4,096-dimension limit against your roadmap. Several current embedding models fit comfortably under it. If you are planning around a model above it, that is a hard limit. No setting gets around it.

## When S3 Vectors is the better choice

S3 Vectors was built for a large corpus that is queried occasionally. It wins that case decisively. Storage at object-storage prices, nothing running while idle, and no capacity to plan add up to a cost no provisioned system can match.

Good fits include archives, compliance records, per-customer document sets searched a few times a day, and anything where you store far more embeddings than you query. An early project fits too, when you do not yet know the query rate and committing to provisioned capacity would be a guess.

Look elsewhere if you run a sustained query rate against a large index, because the charge for processing the whole index on every query becomes the largest line on the bill. The same goes for any requirement that needs a control S3 Vectors does not expose.

## Moving from S3 Vectors

Vectors move as a bulk export and load. Pinecone imports from object storage, where your vectors already are.

- [Import records from object storage](https://docs.pinecone.io/guides/index-data/import-data)

## Frequently asked questions

### Is Pinecone a good alternative to Amazon S3 Vectors?

Pinecone is the better choice when queries are sustained, because its Dedicated Read Nodes turn read cost into a fixed monthly rate while S3 Vectors prices every query against the size of the whole index. It is also the better choice if you need a way to tune queries, more than 4,096 dimensions, or retrieval that runs somewhere other than AWS. If your corpus is large and queried rarely, S3 Vectors is cheaper.

### Is Pinecone cheaper than Amazon S3 Vectors?

It depends entirely on query rate. S3 Vectors is cheaper across a wide range of query rates. Because storage is priced like object storage, an idle index costs almost nothing. Sustained querying against a large index changes that. S3 Vectors computes the data processed charge from the whole index on every query, while Pinecone's Dedicated Read Nodes charge a flat monthly rate regardless of how many queries you run. Both vendors publish list prices. Use them to work out where the crossover falls for your own corpus size and query rate. Do not rely on a number from either of us.

### Does S3 Vectors have a compute tier I need to size?

No. That is the point of the service. There is no node, replica, or cache tier and nothing to provision or scale. In exchange, you have nothing to add when queries get slower or more expensive and no parameter for tuning queries.

### What are the main limits to check before choosing S3 Vectors?

Dimensions are capped at 4,096. An index holds up to 2 billion vectors, with up to 10,000 indexes per vector bucket and 10,000 buckets per region per account. Writes are limited to 1,000 combined put and delete requests per second per index and 2,500 vectors per second. Metadata is capped at 40 KB per vector with up to 50 keys. Of that 40 KB, at most 2 KB can be filterable. Separately, an index can declare at most ten non-filterable metadata keys. Dimension, distance metric, and the non-filterable metadata keys are all fixed when the index is created.

### Why do my S3 Vectors query costs stay high after deleting vectors?

AWS documents that reclaiming the storage of overwritten or deleted vectors can take up to a day. The vectors disappear from query results immediately, but they keep counting toward the index's storage size until the storage is reclaimed. Because the data processed charge is computed from index size, queries during that window are billed as though those vectors were still there. AWS notes that workloads which frequently overwrite the same keys can temporarily see higher query costs.

### Can I use both?

Yes. For some architectures, using both is the sensible design. A common setup keeps a large archive in S3 Vectors for occasional retrieval and puts the actively queried working set in Pinecone, where read cost is predictable. AWS also documents an integration that exports S3 Vectors into OpenSearch for workloads that need lower latency. Compare that path with moving the working set to a managed service, where you do not operate a cluster.

## Sources

- [Amazon S3 pricing, including the S3 Vectors query charges](https://aws.amazon.com/s3/pricing/)
- [S3 Vectors limitations and restrictions](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-limitations.html)
- [Using S3 Vectors with Amazon OpenSearch Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-opensearch-integration.html)
- [Dedicated Read Nodes: now generally available](https://www.pinecone.io/blog/dedicated-read-nodes-ga/)
- [How Pinecone works](https://www.pinecone.io/how-pinecone-works/)