What happened
Pinecone’s GitHub release for Terraform Provider v5.1.0 was published on October 20. The release updates the provider to go-pinecone v7.1.0, retains the API version used by v5.0.0, 2026-07, and says that no resources or fields were removed or renamed.
The release adds integrated embedding for string fields in document indexes. Pinecone’s release notes say a field can use embed with a dense model, sparse_embed with a sparse model, or both. Pinecone then embeds a field’s text when a document is upserted or updated, and embeds query text when a search uses the corresponding scoring mode. An empty embed configuration selects llama-text-embed-v2 at its default dimension and metric; an empty sparse_embed configuration selects pinecone-sparse-english-v0. Teams can instead set a model, dimension, metric, and model read or write parameters explicitly.
Pinecone says text is stored by default and stored fields are indexed for full-text search. A single field can therefore combine full-text search, dense embedding, and sparse embedding. Setting store_text = false embeds a field and then discards its text, which the release positions for similarity-only fields or cases where a team does not want the original text retained in Pinecone. The configuration has structural limits: an index has one dense slot and one sparse slot, so at most one field can use embed or be a dense-vector field, and at most one can use sparse_embed or be a sparse-vector field.
Integrated embedding is fixed when the index is created. Pinecone’s release notes say changing it replaces the index. The provider also handles imports of indexes that already use integrated embedding: matching configured read or write parameters only update Terraform state on the first plan after import. But if an imported field uses integrated embedding and its Terraform configuration omits embed or sparse_embed, the plan fails rather than replacing the index. Pinecone advises adding the relevant empty configuration to represent the existing index.
The other material change concerns BYOC indexes, where the data plane runs in a customer cloud environment. New BYOC indexes no longer need read_capacity.dedicated. If a new configuration omits read capacity, it defaults to on-demand capacity, matching serverless indexes. Existing dedicated configurations remain valid. However, Pinecone says moving an existing index from dedicated capacity back to on-demand remains rejected. The release also clarifies that terraform taint, rather than terraform apply -replace, is the supported route for recreating an index when replacement protections would otherwise stop planning.
What the archive adds
New Runtime’s earlier coverage of Pinecone BYOC on September 24, 2026 described managed knowledge infrastructure operating inside a customer-controlled cloud boundary. An October 21, 2026 note on on-demand mode described its move from per-index upfront sizing to a shared capacity pool. This is a new provider release and a new implementation detail on that known story: on-demand is now the Terraform default for new BYOC indexes.
Trend signal
This does not yet fit a pattern New Runtime tracks. The release changes a provider default and adds a schema feature, but Pinecone does not report completed-work economics, interoperability, or a new runtime security boundary.
Why now
The timing follows Pinecone’s earlier move to on-demand BYOC capacity. This provider release carries that operating model into infrastructure-as-code defaults for new indexes, while keeping dedicated configurations working for teams that already use them.
Connections to other events
New Runtime’s September coverage established BYOC as Pinecone’s customer-cloud deployment model, while the October note described on-demand capacity as a shared-pool alternative to upfront index sizing. Version 5.1.0 connects those service-level changes to the Terraform workflow that teams use to define and create indexes.
Why it matters
Infrastructure defaults become product decisions when a team uses Terraform to create environments repeatedly. New BYOC configurations can now omit dedicated read capacity, which simplifies the initial definition. But it is not a reversible migration switch: teams with dedicated indexes cannot use this release to move those existing indexes back to on-demand. Capacity mode should therefore remain an explicit review point for workloads that already run in production.
Integrated embedding centralizes another part of retrieval architecture in the index definition. A team can have Pinecone embed documents during writes and embed queries during search instead of maintaining a separate application-side embedding step. That may simplify an ingestion path, but it makes index creation more consequential. The choice is fixed at creation and a change replaces the index. Teams should also decide deliberately whether stored text is needed for retrieval, auditing, or application behavior before setting store_text = false.
What happens next
- New BYOC Terraform definitions will increasingly omit dedicated read capacity. (6 months, 70%). Watch for: Pinecone examples and customer configurations creating BYOC indexes without
read_capacity.dedicated. - Teams adopting integrated embedding will encode embedding settings in initial index modules rather than treat them as routine updates. (6 months, 65%). Watch for: reusable Terraform modules exposing
embed,sparse_embed, and replacement warnings.
Limits and uncertainty
Pinecone’s release describes configuration behavior, not measured operational outcomes. It does not quantify on-demand capacity cost, latency, throughput, scaling behavior, or workload suitability relative to dedicated capacity. It also does not report adoption of either the BYOC default or integrated embedding.
The release lists supported configuration semantics but does not independently evaluate retrieval quality for the default dense or sparse models. It does not state usage prices for embedding, capacity, or index replacement, nor does it describe a migration method from an existing dedicated index to on-demand. Teams should test representative data, queries, traffic, and recovery procedures before interpreting the new defaults as a cost or performance improvement.
Skill to build now
Review the Terraform modules that create Pinecone indexes. Make capacity mode explicit even if the new BYOC default is acceptable, and add a review guard for fields using embed or sparse_embed because changing those settings replaces the index. For similarity-only text fields, test whether store_text = false preserves the application behavior and governance controls your team needs.
Reader takeaway
Pinecone’s provider now makes on-demand capacity the starting point for new BYOC indexes and lets document-index schemas own embedding configuration. The practical benefit is less setup work, but the trade-off is that capacity and embedding choices must be made carefully at creation time because the release does not offer a simple path back from dedicated capacity or a non-replacement embedding change.
Open question
Will Pinecone publish cost, latency, and throughput guidance that lets teams choose between on-demand and dedicated BYOC read capacity for specific production workloads?