Pinecone vs Amazon S3 Vectors
S3 Vectors puts a nearest-neighbor API on top of object storage. Nothing is provisioned, idle costs nothing, and storage is priced like storage. That makes it genuinely hard to beat for a large corpus you query occasionally. The question this page is about is what happens when the query rate goes up.
Pinecone wins once queries are sustained, because Dedicated Read Nodes turn read cost into a flat monthly figure while S3 Vectors keeps pricing every query against 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.
The short version
These two are priced on different things, which is most of the comparison. S3 Vectors charges per query against the size of the index being queried. Pinecone charges for reads you perform, and Dedicated Read Nodes replace that with a fixed monthly rate for provisioned capacity.
The consequence is that the two cross over at some query rate. Below it, S3 Vectors is cheaper and often dramatically so, because an idle index costs only storage. Above it, a workload paying full-index data processing on every query passes the flat rate of provisioned capacity. Where that crossover sits depends on your corpus size and query rate, and both vendors publish the list prices you need to work it out.
Read the rest of this page for the parts a spreadsheet will not show you: what you can tune, what is fixed at index creation, and where the service ceilings sit.
When to pick which
Both systems have workloads they suit. This is where each one is the better answer.
Choose Pinecone when
- Query volume is sustained rather than occasional, and predictable read cost matters.
- You want a knob. S3 Vectors exposes no tuning parameter on the query path.
- The corpus changes continuously and you would rather not have 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. This is the case S3 Vectors is built for and it is a strong one.
- Scale-to-zero economics matter more than per-query cost, for example an archive searched a few times a day.
- You are committed to AWS and want retrieval inside the same account, IAM, and billing boundary.
- You are already using the OpenSearch integration to move vectors between tiers.
Feature by feature
How Pinecone and S3 Vectors differ across the capabilities that usually decide the choice.
| Capability | Pinecone | S3 Vectors |
|---|---|---|
| Deployment model | PineconeYou create an index and write to it. Storage sits on object storage, queries run on executors Pinecone operates, and there is no instance, node count, or cluster topology to choose. | S3 VectorsA vector bucket and an index inside it. There is no node, replica, or cache tier to choose, and nothing to provision. |
| Scaling model | PineconeAutomatic on the on-demand tier, where there is no shard or replica count to choose. Dedicated Read Nodes are provisioned capacity: shards and replicas are set by hand today. | S3 VectorsStorage scales on its own. There is no compute to scale, which also means there is nothing to add when queries get slower or more expensive. |
| Pricing model | PineconeReads and writes you perform, plus storage. Dedicated Read Nodes replace per-query read cost with a fixed monthly rate. | S3 VectorsA per-query request fee, a charge for data processed, and a charge for data returned, plus storage and uploads. Data processed is computed from the average vector size multiplied by the number of vectors in the index, with lower per-terabyte rates above 100,000 and 10 million vectors. |
| Tuning the query | PineconeRead capacity is a tier choice. Indexing and quantization are handled during compaction. | S3 VectorsNo parameter on the query path. Recall and latency are whatever the service does. |
| Changing the index later | PineconeDimension and metric are fixed at creation here too. Indexing and quantization are revised during compaction without a reindex. | S3 VectorsDimension, distance metric, and which metadata keys are non-filterable are all set at creation and cannot change afterward. |
| Embedding dimensions | PineconeUp to 20,000 dimensions for dense vectors. | S3 Vectors1 to 4,096. |
| Multi-tenancy | PineconeNamespaces inside one index, with no per-tenant provisioning. The documented ceiling is 100,000 namespaces per index on Standard and Enterprise. Dedicated Read Nodes support one namespace per index today, which means that tier and the multi-tenancy argument do not currently combine. | S3 VectorsAn index per tenant, up to 10,000 indexes per vector bucket and 10,000 buckets per region per account. A fully isolated index rather than a namespace inside a shared one. |
| Running it in your own cloud | PineconeBring your own cloud on AWS, Azure, and GCP. | S3 VectorsNo equivalent. S3 Vectors runs in your AWS account, and only on AWS. |
S3 Vectors by the numbers
AWS documents these itself. They are the numbers that 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, and 2,500 vectors per second
up to a day
that deleted or overwritten vectors keep counting toward index storage, and therefore toward query cost
A query is priced from the index, not from the query
This is the mechanism worth understanding before anything else, because it is where the architecture shows up on the invoice. AWS states it plainly: the data processed charge is calculated from the average vector size, including vector data, key, and metadata, multiplied by the number of vectors in the index you are querying.
So the charge does not describe work the query did. A top-10 lookup and a top-1,000 lookup against the same index process the same amount of billable data, and adding vectors to an index raises the price of every query against it, including the ones that would never have touched the new vectors.
AWS softens the curve at scale, with lower per-terabyte rates above 100,000 and above 10 million vectors, and non-filterable metadata is excluded from the calculation. The shape holds: cost per query is a function of corpus size.
Pinecone prices reads you perform. Dedicated Read Nodes go further and replace per-query cost with a fixed monthly rate for provisioned capacity, which is the same shape a search cluster gives you without the cluster. Somewhere between an occasional query and a sustained one, those two lines cross. Both vendors publish list prices, and the crossover is worth computing against your own corpus size and query rate rather than taking from either of us.
Deleted vectors keep costing you until they are reclaimed
A detail from the pricing page that follows directly from the model above. When you overwrite or delete a vector, AWS removes it from query results immediately. Reclaiming the storage can take up to a day. During that window the vector still counts toward the index size.
Since query cost is computed from index size, that means a workload which frequently rewrites the same keys pays query charges on vectors it has already deleted. AWS says so directly: those workloads can temporarily see higher query costs.
How much this matters is a question about your write pattern rather than a flaw. A corpus loaded once and read for months will never notice. A pipeline that re-embeds and rewrites documents nightly is paying for yesterday's copies while today's are being served.
Pinecone rewrites slabs during compaction and does not bill queries against deleted records waiting to be reclaimed. Our own write path has a different shape worth knowing about: upserts bill a five-write-unit minimum per record, which makes streaming single vectors more expensive per vector than batching them. Both services reward batching.
There is no dial
S3 Vectors exposes no tuning parameter on the query path. There is no ef_search, no probe count, no oversample factor, and no rerank depth. You send a query and take what the service returns.
Read that as the deliberate trade it is rather than as an omission. Removing the dial is what allows the service to have 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. It is the same instinct behind Pinecone not exposing an index type.
Where the two differ is what happens when the default is not good enough. On Pinecone, read capacity is a tier you can change, and indexing and quantization are revised automatically during compaction as the data grows. On S3 Vectors, the query path is what it is, and the remaining lever is architectural: AWS documents an integration that exports vectors into OpenSearch when a workload needs low-latency or tunable search, which means running the second system you were avoiding.
One thing neither of us can offer you here: a published recall-versus-selectivity curve. If filtered recall is decisive for your workload, test both against your own filter distribution rather than trusting either vendor's description of its own filtering.
What you decide on day one and cannot revisit
Dimension, distance metric, and the list of non-filterable metadata keys are all set when the index is created and none of them can change afterward. Changing any of them means creating a new index and reloading it.
Dimension and metric being immutable is not a difference between us, which makes presenting it as one dishonest: a Pinecone index fixes both at creation too. The non-filterable-keys decision is the one worth planning for, because it is easy to make early and expensive to discover late, and because it interacts with cost. Non-filterable metadata is excluded from the data processed charge, which means the choice affects both what you can query and what each query costs. Non-filterable keys are capped at ten per index, which makes that a real saving with a low ceiling.
The ceiling worth checking against your roadmap is 4,096 dimensions. Several current embedding models sit under it comfortably. If you are planning around a model above it, that is a hard stop rather than a tuning exercise.
When S3 Vectors is the right answer
A large corpus that is queried occasionally is the case this service was built for. It wins that case decisively. Storage priced like object storage, nothing running while idle, and no capacity to plan is a combination no provisioned system can match on cost.
Archives, compliance corpora, per-customer document sets that are searched a few times a day, and anything where the embedding volume dwarfs the query volume all sit comfortably here. So does an early project where the query rate is unknown and committing to provisioned capacity would be a guess.
The reason to look elsewhere is a sustained query rate against a large index, where full-index data processing on every query becomes the dominant line on the bill, or a requirement that needs a lever the service does not expose. Those are the conditions the rest of this page describes.
Moving from S3 Vectors
Vectors move as a bulk export and load. Pinecone imports from object storage, which is where your vectors already are.
Talk to an engineer or read how Pinecone works.
Frequently asked questions
It is the better choice when queries are sustained rather than occasional, because Dedicated Read Nodes convert 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 tuning lever on the query path, more than 4,096 dimensions, or retrieval running somewhere other than AWS. If your corpus is large and queried rarely, S3 Vectors is genuinely cheaper and we would tell you so.
It depends entirely on query rate, and the honest answer is that S3 Vectors is cheaper across a wide band. Its storage is priced like object storage and an idle index costs almost nothing. What changes the answer is sustained querying against a large index, because 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. Work out where your own corpus size and query rate put the crossover rather than trusting a number from either of us.
No. That is the point of it. There is no node, replica, or cache tier, and nothing to provision or scale. The trade is that there is also nothing to add when queries get slower or more expensive, and no tuning parameter on the query path.
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 which 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.
AWS documents that it can take up to a day for storage from overwritten or deleted vectors to be reclaimed. The vectors disappear from query results immediately while continuing to count toward the index's storage size until reclamation. Since 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 frequently overwriting the same keys can temporarily see higher query costs.
Yes, and for some architectures it is the sensible answer. A common shape is a large archive in S3 Vectors for occasional retrieval, with 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 needing lower latency, which is worth comparing against moving that working set to a managed service instead of operating a cluster.
Sources
- Amazon S3 pricing, including the S3 Vectors query charges
- S3 Vectors limitations and restrictions
- Using S3 Vectors with Amazon OpenSearch Service
- Dedicated Read Nodes: now generally available
- How Pinecone works
Claims about S3 Vectors last checked against its own documentation on . Competitors ship changes we do not control. If something here is out of date, tell us and we will correct it.
Try it on your own workload
Create your first index for free, then pay as you go when you are ready to scale.