b1
and t1
. Both are suitable for large-scale and demanding workloads, but t1
nodes provide increased processing power and memory. Additionally, t1
nodes cache more data in memory, enabling lower query latency.
Index size | Shards | Capacity |
---|---|---|
100 GB | 1 | 250 GB |
500 GB | 3 | 750 GB |
1 TB | 5 | 1.25 TB |
1.6 TB | 7 | 1.75 TB |
memory_fullness
: How much of the index’s memory capacity is currently in use (0 to 1).storage_fullness
: How much of the index’s storage capacity is currently in use (0 to 1).indexFullness
: The greater of memory_fullness
and storage_fullness
.storage_fullness
is the limiting factor. However, memory can fill up first in the following scenarios:
b1
nodes, a large namespace (hundreds of millions of records), low-dimension vectors (128 or 256 dimensions), and minimal metadata.t1
nodes, high-dimension vectors (1024 or 1536 dimensions), and lots of metadata.2025-10
of the Pinecone API.
spec.serverless.read_capacity
object:
mode
to Dedicated
.dedicated.node_type
to either b1
or t1
, depending on the node type you want to use.dedicated.scaling
to Manual
(currently, Manual
is the only option, and it must be included in the request).dedicated.manual.shards
to the number of shards required to accommodate at least the current size of your index, with a minimum of 1 shard. Each shard provides 250 GB of storage.dedicated.manual.replicas
to the number of replicas for the index, with a minimum of 0 replicas (an index with 0 replicas is paused).embed
object in the request body.
Example request:
chunk_test
with the name of the field in your data that contains the text to be embedded.read_capacity
object to configure node type, shards, and replicas.indexFullness
describes how full the index is, on a scale of 0 to 1. It’s set to the greater of memory_fullness
and storage_fullness
.
spec.serverless.read_capacity.dedicated.manual.replicas
to the desired number of replicas.
Example request:
spec.serverless.read_capacity
object, set the following fields:
mode
to Dedicated
.node_type
to the node type you want to use (b1
or t1
).shards
to the number of shards required for your index. Each shard provides 250 GB of storage.replicas
to the number of replicas required for your query throughput needs.index-to-migrate
to a dedicated index with b1
nodes, 1 shard, and 1 replica:
spec.serverless.read_capacity.status.state
is Ready
.
An Error
state means that you didn’t allocate enough shards for the size of your index. Migrate to dedicated again, using a sufficient number of shards.
spec.serverless.read_capacity.status.state
field. Possible values include:
Ready
: The dedicated index is ready to serve queries.Scaling
: A change to the node type, number of shards, or number of replicas is in progress.Migrating
: A change to the is in progress.Error
: You did not allocate enough shards for the size of your index. Migrate to dedicated again, using a sufficient number of shards.Metric | Limit |
---|---|
Min shards per index | 1 |
Max namespaces per index | 1 |
Node type or changes | 1 per 24 hours |
Max shard or replica changes | 1 per hour |
memory_fullness
is an approximation and doesn’t yet account for metadata.(Dedicated read nodes costs)
+ (storage costs)
+ (write costs)
(Dedicated read nodes costs)
are calculated as:
(Storage costs)
are the same as for on-demand indexes.
(Write costs)
are the same as for on-demand indexes.
b1 nodes, 2 shards, 2 replicas - Standard plan
b1
nodes is $548.96/month, the cost of dedicated read nodes would be as follows:t1 nodes, 2 shards, 2 replicas - Standard plan
t1
nodes is $1,758.53/month, the cost of dedicated read nodes would be as follows: