Pinecone: ein Test der verwalteten Vektordatenbank

PINECONE ist die verwaltete Vektordatenbank, mit der die meisten Retrieval-Prototypen anfangen, und aus einem belastbaren Grund: Ein Index ist ein POST entfernt, es gibt nichts zu betreiben, und die Rechnung wird gemessen statt bereitgestellt. Diese Kombination ist im ersten Jahr einer Retrieval-Funktion wirklich schwer zu schlagen. Sie ist auch der Grund, warum Pinecone aufhört, der richtige Standard zu sein, sobald ein Produkt echten Verkehr hat, denn sein Preismodell belohnt eine Entscheidung, die Teams selten bewusst treffen — wie die Daten partitioniert sind.

Es konkurriert mit zwei ganz verschiedenen Arten von Dingen. Auf der einen Seite die allgemeinen Datenbanken, die eine Vektorspalte bekommen haben: pgvector in PostgreSQL, MongoDB Atlas, Redis. Auf der anderen Seite die spezialisierten Engines, Qdrant und Weaviate, selbst betrieben oder in der Cloud. Das Argument gegen alle lautet operativ: kein Cluster, kein Reindex, kein ANN-Tuning, Kapazität, die erscheint, wenn sie gebraucht wird. Das Gegenargument sind Lock-in, die Kosten pro Query in der Größenordnung und ein Datenmodell, das bewusst kein SQL ist.

Was es ist

Der Index ist die Einheit von allem. Records gehen in einen, Queries treffen einen, und innerhalb davon sind die Daten in Namespaces partitioniert, wobei jeder Upsert, jede Query, jeder Fetch und jedes List genau einen Namespace adressiert. Seit API-Version 2026-07 gibt es zwei Arten von Index, und sie zu unterscheiden ist das Wichtigste, bevor man Code gegen Pinecone schreibt.

• Ein Vector Index ist der klassische: dichte und optional sparse Vektoren, angelegt mit dimension, metric und vector_type, gelesen und geschrieben über die Vectors API.
• Ein Document Index ist der neue: ein Schema, das dense_vector, sparse_vector und Volltext-string-Felder deklariert, gelesen und geschrieben über die Documents API.
• Namespaces entstehen implizit beim ersten Upsert. Einer pro Mandant ist das dokumentierte Multitenancy-Muster, und die Partitionierung nach Namespace senkt zugleich die Lesekosten.
• Metadaten sind ein flaches JSON-Objekt: keine verschachtelten Objekte, keine null-Werte, Schlüssel dürfen nicht mit $ beginnen, Ganzzahlen werden als 64-Bit-Fließkommazahlen gespeichert, und 40 KB sind die Obergrenze pro Record. Alles wird für Filter indiziert, sofern es nicht anders konfiguriert ist.
• Die Filtersprache ist eine dokumentierte Teilmenge: $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin, $exists sowie $and, $or und $not. Die Listenoperatoren nehmen höchstens 10.000 Werte an.
• Sparse-Indizes sind eng: höchstens 2.048 von Null verschiedene Werte pro Vektor, 10 Upserts pro Sekunde, 100 Queries pro Sekunde, ein top_k-Maximum von 10.000 und Dot Product als einzige Metrik.

Wie es funktioniert

In einem Index können drei Ranking-Signale nebeneinander liegen: BM25 über Volltextfelder, dichte Vektoren für Bedeutung und sparse Vektoren für gelernte lexikalische Wichtigkeit. Auf einem Vector Index kombiniert eine Hybrid Query dicht und sparse in einem Aufruf. Auf einem Document Index rankt eine Suche nach genau einem Scoring-Typ, gewählt über score_by, Hybrid Search bedeutet dort also entweder einen Text-Match-Filter, der die Kandidaten vor einer dichten Suche eingrenzt, oder zwei Suchen, die in der Anwendung per Reciprocal Rank Fusion verschmolzen werden.

Das Kostenmodell folgt aus derselben Struktur. Eine Query kostet eine Read Unit pro Gigabyte des gescannten Namespaces, mit einem Minimum von 0,25 Read Units. top_k, include_metadata und include_values ändern daran nichts; allein die Namespace-Größe zählt. Egress wird separat auf die zurückgegebenen Bytes abgerechnet, IDs und Scores eingerechnet. Um den Index herum gibt es drei weitere Dienste, die zu benennen sich lohnt, weil sie verändern, was die Anwendung selbst tun muss: Pinecone Inference hostet Embedding- und Reranking-Modelle und rechnet nach Token oder Rerank-Anfragen ab, Pinecone Assistant macht aus einem hochgeladenen Dokumentbestand einen Chat-Endpunkt mit eigener Token- und Ingestion-Abrechnung, und Pinecone Nexus, gelistet als Knowledge Engine für Agenten, geht mit derselben Idee weiter, indem Retrieval einmal bei einer Datenänderung erledigt wird statt bei jedem Agent-Call.

Wo es bricht

Vier Dinge werden zubeißen, und drei davon sind strukturell statt behebbar.

• Schema-Migration wird nicht unterstützt. Ist ein Dokumentindex einmal angelegt, lassen sich Felder nicht ergänzen, entfernen oder ändern, und der dokumentierte Ausweg ist, den Index zu löschen und einen neuen anzulegen.
• Umwandeln ist nicht möglich. Die Data Plane eines Index steht bei seiner Erstellung fest, ein SDK-Upgrade verschiebt einen alten Vector Index also nie auf die Documents API. Wer Volltextsuche will, braucht einen zweiten Index und ein zweites Einlesen.
• Cloud und Region sind nach der Erstellung nicht mehr wechselbar, und der Starter-Plan ist auf aws us-east-1 beschränkt. Alles mit einer Anforderung an Datenresidenz ist am ersten Tag eine Entscheidung für einen bezahlten Plan.
• Die Lesekosten skalieren mit der Namespace-Größe, nicht mit dem Aufwand. Ein 50-GB-Namespace kostet 50 Read Units pro Query; dieselben Daten in 100 Namespaces à 0,5 GB kosten 0,5. Das ist einhundertfach in der größten Position.
• Unterhalb von Enterprise gibt es keine Verfügbarkeits-SLA, und Enterprise beginnt bei 500 Dollar Mindestumsatz. Standard, der Plan, auf dem die meisten Produktionslasten landen, hat weder SLA noch Audit-Logs.
• Pinecone Local, der lokale Emulator, fährt die API-Version 2025-01, begrenzt einen Index auf 100.000 Datensätze, ignoriert API-Schlüssel und unterstützt weder Namespaces noch Backups noch Pinecone Inference. Das ist eine CI-Bequemlichkeit, keine getreue lokale Umgebung.

Nehmen Sie die dokumentierten Tarife und rechnen Sie. Auf Standard kosten Read Units je nach Cloud und Region $16 bis $18 pro Million. Eine Million Queries gegen einen 50-GB-Namespace sind 50 Millionen Read Units, rund $800 pro Monat allein fürs Lesen. Dieselbe Million gegen 100 Namespaces à 0,5 GB sind 500.000 Read Units, etwa $8. An der Anwendung hat sich nichts geändert, nur an der Partitionierung. Auf Enterprise, wo Read Units bei $24 pro Million beginnen, werden aus denselben beiden Zahlen $1.200 und $12.

Erste Schritte

Das kleinste nützliche Pinecone-Programm ist ein Vector Index mit eigenen Embeddings, ein Namespace pro Mandant und ein Metadatenfilter in der Query. So konvergiert der meiste Produktionscode, und diese Form belohnt das Kostenmodell.

import os
from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])

if not pc.has_index("products"):
    pc.create_index(
        name="products",
        vector_type="dense",
        dimension=1536,
        metric="cosine",
        spec=ServerlessSpec(cloud="aws", region="eu-central-1"),
        deletion_protection="disabled",
    )

index = pc.Index("products")

# One namespace per tenant keeps each read inside a small slice of the index.
index.upsert(
    namespace="tenant-42",
    vectors=[("p-1001", embedding, {"category": "pumps", "price": 249.0})],
)

hits = index.query(
    namespace="tenant-42",
    vector=query_embedding,
    top_k=8,
    filter={"category": {"$eq": "pumps"}, "price": {"$lte": 500}},
    include_metadata=True,
    include_values=False,   # omit the vector: egress is billed on the response
)

Zwei Details in diesem Snippet sind tragend. include_values=False ist der Standard und hält mehrere Kilobyte pro Treffer von der Egress-Rechnung fern, während ein fetch immer Vektorwerte zurückgibt; nutzen Sie also query, wenn Sie suchen und nur IDs oder Metadaten brauchen. Und filter senkt die Read Units nicht: das macht der Namespace. Filter grenzen das innerhalb des bereits gewählten Namespaces Gescannte ein, ein Grund mehr, nicht alles in einen einzigen Namespace zu legen.

Preise

Vier Pläne, jeder mit eigener Form. Starter ist kostenlos mit harten Obergrenzen, Builder ist flach $20 mit harten Obergrenzen, und Standard und Enterprise sind nutzungsabhängig hinter einem Mindestumsatz, der sich wie eine Verpflichtung verhält und nicht wie eine Gebühr.

Drei Anmerkungen. Die Mindestumsätze von $50 und $500 werden als Aufschlagsposition abgerechnet, wenn die Nutzung darunter liegt, ein ruhiger Monat kostet also trotzdem den Mindestumsatz. Read Units kosten auf Standard das Vierfache von Write Units, eine leselastige Retrieval-Anwendung wird also von einer Position dominiert. Und die Pauschalpläne degradieren nicht elegant: Jenseits des Kontingents werden lesende Zugriffe mit einem 429 blockiert statt abgerechnet, was ein ganz anderes Fehlermuster ist als eine überraschende Rechnung, und arguably der bessere der beiden Fälle.

Standard und Enterprise schalten außerdem das frei, was eine Produktionsinstallation irgendwann braucht: Import aus Object Storage für $0,25 pro GB, Backups für $0,10 pro GB und Monat, Restores für $0,15 pro GB sowie Dedicated Read Nodes, die gar nicht in Read Units abgerechnet, sondern nach bereitgestellter Kapazität bepreist werden. Dedicated Read Nodes sind das Feature, das man verstehen sollte, bevor man Pinecone für zu teuer erklärt, denn sie brechen die Read-Unit-Formel, auf der der Rest dieses Artikels beruht.

Alternativen

Der lohnende Vergleich ist nicht gegen jede Vektordatenbank. Er ist gegen die beiden, die das Pinecone-Modell auf eine spezifische, strukturelle Weise brechen.

Die ehrliche Zusammenfassung dieser Tabelle: pgvector gewinnt bei allem außer der Größenordnung, und die Schwelle liegt irgendwo bei zehn Millionen Vektoren, jenseits derer Index-Build-Zeiten und Recall-Tuning in PostgreSQL kein vernünftiger Nachmittag mehr sind. Qdrant gewinnt bei Kontrolle und bei Hybrid Search in einer Query und verliert daran, dass jemand es betreiben muss. Pinecone gewinnt bei der Zeit bis zur ersten Query und darin, keinen Bereitschaftsdienst für einen Suchdienst zu brauchen, und verliert bei den Kosten pro Query, sobald der Index wächst, und daran, dass die Form der Daten nachträglich nicht mehr geändert werden kann. Das sind die Abwägungen, keiner davon ist ein Fehler.

Fazit

Pinecone ist der richtige Standard für die ersten neunzig Tage einer Retrieval-Funktion und eine vertretbare Wahl über Jahre, wenn die Last klein, sauber partitioniert und schwer genug ist, um auf dem Read-Unit-Minimum zu sitzen. Es hört auf, die richtige Antwort zu sein, wenn der Index ein paar Gigabyte überschreitet, wenn eine Compliance-Anforderung eine SLA oder Audit-Logs braucht, oder wenn die Form des Korpus noch in Bewegung ist.

1. Übernehmen, wenn niemand einen Suchcluster besitzen wird. Die kostenlose Stufe ist wirklich nützlich, der erste bezahlte Schritt sind $20 flach.
2. Nach Namespaces partitionieren, bevor der Index groß ist, nicht danach. Diese eine Entscheidung setzt die Leserechnung und ist später viel schwerer zu ändern.
3. Nicht übernehmen für einen Korpus, dessen Felder bei einem Dokumentindex noch in Bewegung sind, weil Schema-Migration nicht unterstützt wird.
4. Mit der eigenen Namespace-Größe rechnen. Die Read-Unit-Formel in der Dokumentation ist kurz genug für den Taschenrechner.
5. Qdrant ansehen, wenn der Index zehn Millionen Vektoren überschreiten wird, und pgvector, wenn er deutlich unter einer Million bleibt und es schon einen Datenbankadministrator gibt.

Quellen

1. Pinecone docs: Index data overview, indexes, namespaces and metadata
2. Pinecone docs: Adopt the Documents API, API version 2026-07
3. Pinecone docs: Create an index, schemas, regions and metrics
4. Pinecone docs: Understanding Pinecone cost, read units, write units and egress
5. Pinecone pricing: plans, limits and rates
6. Pinecone docs: Semantic search
7. Pinecone docs: Local development with Pinecone Local
8. Pinecone docs: 2026 release notes