Pinecone BYOC Reaches General Availability on AWS, Azure and Google Cloud
In its announcement, Pinecone says it is announcing the general availability of Pinecone Bring Your Own Cloud (BYOC) on AWS, Google Cloud, and Azure. The post is dated September 23 in the company newsroom, and Blocks & Files covered it the following day. Pinecone's pricing page now carries a banner saying BYOC is Now Generally Available.
The offering took several steps to get here. It began as an AWS-only program: Pinecone's earlier post said Pinecone's BYOC offering for AWS is now in early access. A February 19, 2026 post then moved it to public preview with a zero-access operating model, self-serve deployment, and support for AWS, GCP, and Azure. As late as August 2026, Pinecone's documentation still said that BYOC is in public preview on AWS, GCP, and Azure. So the September release doesn't add any new clouds. It moves the same three-cloud offering from preview to general availability.
The Blocks & Files headline says Pinecone "released its proprietary cloud lock". That isn't accurate. Pinecone's regular managed service was already multi-cloud. In August 2024, Blocks & Files itself reported that Pinecone has made its AWS-supporting vector database available on the Azure and Google clouds, starting in the "eastus2" (Virginia) region on Azure, and Google Cloud's "us-central1" (Iowa) and "europe-west4" (Netherlands). TechTarget covered the same launch, noting that Pinecone launched its serverless vector database on Microsoft Azure and Google Cloud in a move that enables customers to use the fully managed database on the cloud of their choice. The real change is where the data runs. Your choice of cloud provider was already open.
For the unfamiliar: a vector database stores embeddings, numerical representations of text, images or other content. AI applications search these embeddings to find material that is semantically similar to a query. In a typical RAG setup, that store holds a company's documents in searchable form, so it often contains the most sensitive data in the whole AI stack.
Pinecone's Split-Plane Architecture Puts the Data Plane in Your Subscription
BYOC is built on a split between two layers. Pinecone runs the control plane, which its product page says handles index lifecycle, authentication, user management, billing, and usage visibility, according to the BYOC FAQ. The GA announcement says the control plane does not store or process customer content or request payloads.
The data plane is the part you host. Pinecone says it stores, processes and serves customer data, and applications and AI agents connect to it directly for reads and writes. With BYOC, the data plane runs inside the customer's selected cloud account and region, including those beyond where Pinecone's standard service is available. Vectors, documents, metadata, and request payloads remain within the customer-controlled boundary.
The region point has practical weight. Pinecone's standard hosted service is limited to the regions Pinecone chooses to operate. BYOC lets an organization place the data plane in whichever region its data-residency policy requires, as long as its cloud account can provision the resources there. Pinecone's documentation describes the target audience as organizations with strict requirements around data sovereignty, network isolation, and data residency.
Some data does still flow back to Pinecone. According to Pinecone's February technical post, the items that can leave your account are operational metrics and traces, with CPU, memory and latency given as examples, plus cluster health and operation status. Vectors, metadata, index contents, and query and upsert payloads stay in your account. The GA announcement calls the shared telemetry "anonymized". Security reviewers should confirm exactly what that telemetry contains before signing off. The definition of "operational" data is the part of this design that depends on trusting the vendor.
Zero-Access Operations Replace SSH, VPN and Standing IAM Roles
The most interesting engineering in BYOC is how Pinecone manages a database it can't log into. The GA announcement says Pinecone does not require SSH, VPN, inbound network access, or a standing cross-account IAM role to manage the service. Upgrades, scaling actions, and maintenance work are retrieved using an outbound call from the Pinecone control plane and executed locally.
Pinecone's technical documentation describes the sequence in detail:
- A Pinecone admin on the customer side starts a cluster operation, such as scaling, an upgrade or a restart.
- The Pinecone control plane queues that operation for the customer's environment.
- Components inside the customer's cluster pull pending operations over TLS and run them locally.
- The cluster reports health and state back to the control plane.
The pull model reverses the usual managed-service arrangement. A traditional vendor-managed deployment typically needs a way in, such as a bastion host, a VPN tunnel or a cross-account role the vendor can assume. Under BYOC, you don't open inbound firewall ports for Pinecone to operate the system. Every connection starts from the customer side. For audits, Pinecone's product page says every cluster operation is logged as a Kubernetes custom resource, so administrators can see what ran and when.
"Zero-access" has a specific meaning here. The deployment still keeps an outbound connection to Pinecone's control plane, still sends telemetry and still runs operations that Pinecone queues. What goes away is any persistent path for Pinecone to reach into the environment. Pinecone's own framing supports this reading. The February post says Pinecone has no access to the customer's cloud account but has visibility through metrics and traces and stays on call for support.
Pinecone pitches this as a middle option between two alternatives. A managed service with vendor access is faster to adopt but, in Pinecone's words, can stall in security review. Full self-hosting avoids vendor access but moves upgrades, reliability and incident response entirely onto the customer's team.
What a Pinecone BYOC Deployment Provisions on AKS, EKS or GKE
Deployment is self-serve for Enterprise users. Pinecone's post describes an interactive setup wizard that checks prerequisites and validates cloud quotas, then generates a Pulumi project. The customer deploys it with pulumi up. According to Pinecone, provisioning creates the data plane environment in your cloud account, including a dedicated VPC and an EKS/GKE/AKS cluster, plus supporting cloud services for storage, system state, and TLS/DNS. On Azure, that means an Azure Kubernetes Service cluster in your subscription. Pinecone uses the generic term "VPC" across all three clouds, and its posts don't list the Azure-specific resources the kit creates.
Pinecone recommends a staged rollout. Start in a non-production account whose network and policy controls match production, fold the deployment kit into a CI/CD or GitOps pipeline, then promote the same deployment model to production. Because the kit is infrastructure-as-code, platform teams can review what it creates before running it.
Network exposure is a choice you make. Pinecone documents two modes: Public access enabled: connect using the standard index host URL. Public access disabled: connect only from within your VPC using AWS PrivateLink, GCP PSC, or Azure Private Link and the private host URL. Control-plane operations keep working in either mode, so a private-only setup doesn't lose management features.
Billing has two parts. You pay your cloud provider for infrastructure, and you pay Pinecone a separate usage fee based on the size of your provisioned deployment. Pinecone publishes no BYOC price list and asks customers to contact it for sizing. For Azure customers, this means compute, storage and networking appear on the Azure bill, which may count toward existing consumption commitments. That's an inference worth checking with your Microsoft account team; Pinecone hasn't said so.
Single-Namespace DRN Indexes Are All You Get in BYOC for Now
The biggest limitation is feature coverage. BYOC supports AWS, GCP, and Azure for Enterprise users, including DRN indexes (single-namespace) and the split control plane/data plane architecture. Capabilities that depend on Pinecone-hosted services outside your account (for example, Assistant, Inference, On-Demand indexes, and DRN integrated embedding) are not available in BYOC today.
DRN stands for Dedicated Read Nodes, Pinecone's provisioned-capacity index type. BYOC currently offers only single-namespace DRN indexes, not the on-demand indexes that many developers start with, and not DRN with integrated embedding. The missing features share one trait: each depends on Pinecone-hosted services outside the customer's account. That fits the design logic. Pinecone's Inference service generates embeddings on Pinecone's infrastructure, so offering it inside BYOC would send customer content outside the boundary BYOC is meant to protect.
In practice, BYOC customers need their own embedding pipeline. Content has to be turned into vectors before upsert, using a model the customer runs or has already approved. Teams that use Pinecone's integrated embedding or Assistant on the standard service can't move those workloads over unchanged.
What does carry over is the developer interface. Pinecone says teams use the same APIs, SDKs and control-plane workflows across BYOC and standard deployments, and its February post lists compatibility with the Pinecone CLI. That lets organizations mix models, keeping low-sensitivity workloads on the hosted service and moving regulated ones into BYOC without maintaining two codebases.
Pinecone's named reference customer is Toyota Motor North America. The company describes TMNA as one of its first BYOC customers, using the service to ground AI applications in decades of proprietary manufacturing knowledge. Kordel France, TMNA's Head of AI Engineering, said in Pinecone's announcement that BYOC "runs inside our own environment, so that knowledge never leaves our boundary and is served only to models we've already vetted." That is a customer testimonial published by the vendor. It includes no performance or cost figures.
Air-Gapped, Self-Managed Pinecone Is Still Under Development
BYOC still depends on Pinecone's control plane, so it doesn't suit environments with no outbound connectivity at all. Pinecone says it is developing a fully self-managed option for air-gapped and highly restricted networks, with both the control plane and data plane running inside the customer environment. It gives no release date, pricing or feature list, and invites interested customers to help shape the requirements. For now, this is a roadmap item and not an on-premises product you can buy.
Pinecone is also catching up with its competitors here. Blocks & Files notes that Zilliz Cloud offers both SaaS and BYOC on AWS, Google Cloud and Azure. It also reports that Weaviate can be self-hosted on EKS, AKS or GKE, with dedicated deployments across all three clouds and an Azure Marketplace listing for customer tenants, and that Qdrant supports all three clouds plus a hybrid option. For buyers, BYOC closes a gap in Pinecone's lineup more than it gives Pinecone an edge.
What this means for you
If an AI project is stuck because security teams won't allow customer data in a vendor-hosted vector store, Pinecone BYOC on Azure, AWS or Google Cloud is now a supported, generally available option worth evaluating. Check first that your workload fits within single-namespace DRN indexes and that you can produce embeddings yourself. Teams that rely on Pinecone Assistant, Inference or on-demand indexes, or that need no outbound connectivity at all, should stay on the standard service or wait for the self-managed option.
- BYOC requires a Pinecone Enterprise plan and currently supports only single-namespace Dedicated Read Nodes indexes.
- Pinecone Assistant, Inference, Database On-Demand indexes and DRN integrated embedding are not available in BYOC, so embeddings must be generated before upsert.
- The data plane runs on a Pinecone-provisioned EKS, GKE or AKS cluster in your account, deployed through a Pulumi project that the setup wizard generates.
- You can disable public endpoints and connect only through Azure Private Link, AWS PrivateLink or Google Cloud Private Service Connect without losing control-plane functions.
- The cluster keeps outbound TLS connectivity to Pinecone's control plane and sends operational metrics and traces, so security reviews should confirm that telemetry is acceptable.
- Budget for two bills: your cloud provider's infrastructure charges plus a separate Pinecone usage fee based on provisioned deployment size.
The GA label settles the main question enterprise buyers had: Pinecone now offers a supported way to keep vectors and query payloads inside an organization's own Azure, AWS or Google Cloud account without giving the vendor a way in. The limits are just as clear. BYOC is a restricted version of Pinecone that still reports to Pinecone's control plane, and the fully disconnected version regulated industries may want has no ship date. Until feature coverage expands beyond single-namespace DRN indexes, BYOC makes most sense for teams whose main blocker is data residency, not missing features.