Pinecone BYOC: Neuer On-Demand-Modus erspart Teams die Dimensionierung von Indizes

Pinecone hat sein Angebot Bring Your Own Cloud (BYOC) um einen On-Demand-Kapazitätsmodus erweitert. Kunden können damit Indizes anlegen, ohne jeden einzeln dimensionieren zu müssen. Laut Unternehmen teilen sich On-Demand-Indizes einen gemeinsamen Kapazitätspool, der Millionen von Namespaces fassen kann.
- Pinecone BYOC unterstützt jetzt den On-Demand-Kapazitätsmodus, der allen BYOC-Kunden zur Verfügung steht.
- On-Demand-Indizes teilen sich einen Kapazitätspool, der Millionen von Namespaces fassen kann.
- Dank dynamischem Sharding lassen sich Shards hinzufügen, ohne Indizes neu aufzubauen oder vorhandene Daten zu verschieben.
- Ein stark abgefragter Namespace kann in einen eigenen Index auf dedizierten Read-Nodes im selben Cluster verschoben werden.
- Laut Pinecone bleibt das Zero-Access-Modell bestehen: Die Daten verbleiben im Cloud-Konto des Kunden.
Was der On-Demand-Modus ändert
Pinecone BYOC betreibt Pinecone im eigenen AWS-, Google-Cloud- oder Azure-Konto des Kunden. Die Daten bleiben unter der Kontrolle des Kunden, während Pinecone die Datenbank betreibt. Das Unternehmen erklärt, dass sich vor allem Teams aus den Bereichen Recht, Gesundheitswesen und Finanzdienstleistungen dafür entscheiden, um ihre Daten in der eigenen Cloud zu halten.
Mit dem neuen Modus, den Manish Talreja am 15. Oktober 2026 in einem Blogbeitrag vorgestellt hat, greifen alle On-Demand-Indizes auf einen gemeinsamen Pool zu. Jeder Namespace kann dabei einen Mandanten (Tenant) einer App oder einen Nutzer eines KI-Agenten abbilden. Kunden starten mit einem kleinen Pool und fügen Kapazität hinzu, sobald ihre Daten wachsen.
Das Sharding-Problem, das der Modus adressiert
Pinecone beschreibt ein verbreitetes Problem in Suchsystemen, egal ob semantisch oder lexikalisch: Nutzer müssen bei der Erstellung jedes Index die Anzahl der Shards festlegen. Wer zu wenige wählt, muss den Index neu aufbauen, sobald er über sie hinauswächst. Wer zu viele wählt, zahlt für ungenutzte Hardware. Werden später Shards hinzugefügt, müssen bestehende Daten verschoben werden, und einige Shards sind trotzdem deutlich voller als andere.
Der On-Demand-Modus setzt auf dynamisches Sharding. Statt einen Index an feste Shards zu binden, erfasst das System, wo jeder Teil jedes Index liegt. Laut Pinecone können Kunden Shards hinzufügen, ohne etwas neu aufzubauen oder vorhandene Daten zu verschieben. Neue Daten landen auf den Shards mit dem meisten freien Platz, sodass die Daten gleichmäßig über den Pool verteilt bleiben.
Erhält ein Namespace deutlich mehr Abfragen als die übrigen, lässt er sich in einen eigenen Index auf dedizierten Read-Nodes im selben BYOC-Cluster verschieben. Die restlichen Namespaces teilen sich weiterhin den On-Demand-Pool.
Sicherheits- und Supportmodell
Pinecone betont, dass die Skalierung des Pools das Zero-Access-Modell von BYOC wahrt. Vektoren, Metadaten und Abfragen bleiben im Cloud-Konto des Kunden. Pinecone fügt Kapazität hinzu, ohne SSH, VPN, eingehenden Netzwerkzugriff oder eine dauerhafte kontoübergreifende Rolle.
Das Unternehmen überwacht den Zustand der Cluster anhand von Betriebsmetriken wie CPU-Auslastung und Latenz, ohne Kundendaten einzusehen. Wenn Hilfe nötig ist, geben Kunden dem Pinecone-Support Logs frei, damit beide Seiten gemeinsam die Fehlersuche betreiben können.
Verfügbarkeit und Einstieg
Der On-Demand-Modus ist ab sofort für alle BYOC-Kunden verfügbar. Neukunden nutzen den Einrichtungsassistenten von Pinecone, der ein Deployment-Projekt erzeugt, das im eigenen Cloud-Konto ausgeführt wird, um den Cluster anzulegen. Bestehende BYOC-Kunden haben bereits einen einsatzbereiten Cluster.
Um einen On-Demand-Index zu erstellen, wählen Nutzer in der Pinecone-Konsole, der API oder den SDKs ihren BYOC-Cluster als Speicherort und On-Demand als Kapazitätsmodus. Für die Cluster-Planung verweist Pinecone Kunden an das jeweilige Account-Team. Außerdem empfiehlt das Unternehmen seinen BYOC-Leitfaden, der die Architektur und die Absicherung der Daten behandelt, sowie die BYOC-FAQ.
Für Multi-Tenant-Anwendungen und KI-Agenten mit vielen Namespaces pro Nutzer bedeutet die Neuerung laut Beschreibung des Unternehmens, dass die Kapazitätsplanung nicht mehr für jeden Index einzeln erfolgen muss.

