Pinecone: Was es ist und wie man es nutzt

Unser Interesse ist fast null und trotzdem erwähnenswert: wir sind Geonode und verkaufen Proxys, die mit Vektordatenbanken nichts zu tun haben. Die eine Berührung ist, dass ein Retrieval-System etwas braucht, worüber es sucht, und wenn dieser Inhalt aus dem öffentlichen Web kommt, muss ihn jemand einsammeln — das ist unser Ende der Pipeline und vollständig getrennt von der Datenbank. Nichts in diesem Artikel verlangt, etwas bei uns zu kaufen, und der Abschnitt gegen eine verwaltete Vektordatenbank steht drin, weil das häufig die richtige Antwort ist.

Was eine Vektordatenbank tut

Gewöhnliche Datenbanken matchen exakt. Eine Vektordatenbank matcht nach Ähnlichkeit.

Der Mechanismus: ein Embedding-Modell wandelt Text, Bilder oder andere Inhalte in eine Zahlenliste um — einen Vektor — so platziert, dass Ähnliches nahe beieinander landet. Relevante Ergebnisse zu finden wird zum Finden naher Punkte, ein Geometrieproblem statt String-Matching.

Pinecone beschreibt sich als „the vector database for AI agents and applications, built for semantic search, knowledge retrieval, and long-term memory at scale“, mit der Fähigkeit, „through billions of items for similar matches to any object, in milliseconds“ zu suchen.

Dass daraus Infrastruktur statt einer Bibliothek wurde, liegt an der Skalierung. Eine Anfrage mit einer Million Vektoren per Brute Force zu vergleichen ist einfach und langsam; das in Millisekunden zu tun, braucht Approximate-Nearest-Neighbour-Indexes, und die zuverlässig im großen Maßstab zu betreiben ist ein Operationsproblem. Genau das verkauft ein Managed Service.

Der dominante Anwendungsfall ist Retrieval-Augmented Generation: zu einer Nutzerfrage die relevantesten Passagen aus den eigenen Dokumenten finden und einem Sprachmodell als Kontext geben. Die Datenbank liefert den Schritt „die relevanten Passagen finden“.

Indexes, Dokumente und Records

Pinecones Datenmodell hat die Form gewechselt und ist in seinem aktuellen Stand wert, verstanden zu werden.

Ein Index ist der Ort, an dem Daten leben. Die Dokumentation erklärt: „a serverless index holds your data as documents or records, depending on how the index was created: an index created with a document schema holds documents, while an index created with a dense or sparse vector type holds records“.

Ein Dokument-Schema lässt einen Index mehrere Jobs erledigen. Laut Dokumentation kann „a single index with a document schema can mix multiple ranking field types: a dense_vector field for semantic search, a sparse_vector field for sparse-vector retrieval, and one or more string fields with full_text_search enabled for full-text search with BM25 and Lucene queries.“

Metadaten brauchen keine Deklaration. „Any other fields you upsert are stored as metadata, automatically indexed for filtering — no schema declaration required.“

Die Design-Empfehlung steht klar: „One index per use case is the typical pattern. Because a document can combine vectors, text, and metadata in the same record, a single index often covers what previously required two — pick the ranking signal per query with score_by.“

Dieser letzte Punkt ist der wesentliche. Volltextsuche steht neben Vektorsuche im selben Index zur Verfügung — „BM25 token matching with Lucene query syntax over text fields in your schema“, wobei Pinecone „tokenization, IDF, and length normalization at index time and BM25 scoring at query time“ übernimmt. Keine separate Suchmaschine, und für die Keyword-Hälfte kein Modell nötig.

Die praktische Folge: hybride Suche — semantische Ähnlichkeit mit exaktem Keyword-Matching zu kombinieren — ist eine Entscheidung zur Query-Zeit, keine Architektur. Das zählt, weil reine Vektorsuche bei exakten Kennungen, Produktcodes und seltenen Eigennamen notorisch schwach ist, und BM25 genau darin stark.

Namespaces

Das Feature, das das Design einer Multi-Tenant-Anwendung am stärksten prägt.

Die Dokumentation: „Within an index, records are partitioned into namespaces, and all upserts, queries, and other data read and write operations always target one namespace.“

Zwei Vorteile werden genannt. Multitenancy — „when you need to isolate data between customers, you can use one namespace per customer and target each customer's writes and queries to their dedicated namespace.“ Und schnellere Queries — „when you divide records into namespaces in a logical way, you speed up queries by ensuring only relevant records are scanned.“

Drei betriebliche Hinweise.

Sie entstehen implizit. „Namespaces are created automatically during upsert. If a namespace doesn't exist, it is created implicitly.“ Praktisch — und ein Tippfehler im Namespace-Namen erzeugt eine still leere Suche statt eines Fehlers.

Das Limit hängt vom Tarif ab. „Namespaces per serverless index vary by plan. On the Standard and Enterprise plans, Pinecone can accommodate million-scale namespaces and beyond for specific use cases. If your application requires more than 100,000 namespaces, contact Support.“

Isolation ist der Punkt. Für alles, was Daten mehrerer Kunden hält, ist ein Namespace pro Kunde das Muster; Cross-Tenant-Leakage wird dann zur Frage, einen Parameter richtig zu setzen, nicht einen Filter.

Embeddings: Ihre oder deren

Zwei Ansätze, und die Wahl hat echte Folgen.

Integriertes Embedding. Die Dokumentation beschreibt es in vier Schritten: „Create an index that is integrated with one of Pinecone's hosted embedding models. Upsert your source text. Pinecone uses the integrated model to convert the text to vectors automatically. Search with a query text. Again, Pinecone uses the integrated model to convert the text to a vector automatically.“

Einfacher — Sie senden Text und erhalten Ergebnisse, ohne eigene Embedding-Pipeline. Eine dokumentierte Einschränkung: „Indexes with integrated embedding do not support updating or importing with text.“

Eigene Vektoren mitbringen. Sie betreiben das Embedding-Modell, legen einen Index an, der zu seinen Eigenschaften passt, und upserten Vektoren direkt, mit „the same external embedding model to convert a query to a vector“.

Mehr Arbeit, mehr Kontrolle. Sie können ein Modell nutzen, das Pinecone nicht hostet, Embedding lokal aus Datenschutz- oder Kostengründen laufen lassen und — entscheidend — Modelle nach eigenem Zeitplan wechseln.

Die Überlegung, die es für viele entscheidet: ein Wechsel des Embedding-Modells bedeutet, alles neu zu embedden. Vektoren verschiedener Modelle sind nicht vergleichbar, ein Wechsel ist also ein vollständiges Re-Index. Integriertes Embedding macht den Erstaufbau leicht und bindet die Entscheidung an den Modellkatalog des Anbieters; eigene Vektoren machen den Aufbau schwerer und lassen die Wahl bei Ihnen. Beides ist nicht falsch, und man sollte bewusst entscheiden statt nach dem ersten Tutorial.

Daten in großem Maßstab laden

Ein Kostenhinweis, den man leicht übersieht und teuer entdeckt.

Die Dokumentation ist konkret: „To control costs when ingesting large datasets (10,000,000+ records), use import instead of upsert.“

Es gibt zwei Ingestionswege. Upsert schickt Records über die API. Import liest Parquet-Dateien aus Object Storage, und die Dokumentation nennt das „the most efficient and cost-effective way to load large numbers of records into an index“.

Da Writes pro Million Write Units abgerechnet werden, ist der Unterschied dieser beiden Pfade bei einem großen Erstimport eine echte Zahl, kein Rundungsfehler. Wenn Sie einen Index über Millionen Records aufbauen, planen Sie den Import-Pfad von Anfang an — ihn nach einem teuren ersten Load nachzurüsten, ist eine Lektion, die niemand zweimal bezahlen muss.

Praktischer Einstieg

Die Form einer ersten Implementierung und die Entscheidungen, die darin stecken.

Index anlegen und upserten. Mit integriertem Embedding ist der Ablauf kurz — Sie berühren nie einen Vektor:

from pinecone import Pinecone

pc = Pinecone(api_key=API_KEY)

index = pc.Index(host=INDEX_HOST)

index.upsert_records(
    namespace="customer-42",
    records=[
        {"_id": "doc-1", "chunk_text": "Refunds are processed within 14 days.",
         "source": "policy.pdf", "page": 3},
        {"_id": "doc-2", "chunk_text": "Shipping to the EU takes 3-5 working days.",
         "source": "shipping.pdf", "page": 1},
    ],
)

Beachten Sie, dass source und page nie deklariert wurden. Alles jenseits der Ranking-Felder wird als Metadaten gespeichert und automatisch für Filter indexiert — Felder lassen sich später ohne Migration ergänzen.

Query mit Filter:

results = index.search(
    namespace="customer-42",
    query={"inputs": {"text": "how long do refunds take?"}, "top_k": 5,
           "filter": {"source": {"$eq": "policy.pdf"}}},
)

Drei Entscheidungen in diesem Snippet sollte man bewusst treffen.

Chunk-Größe. Der Text, den Sie upserten, ist die Einheit, die zurückkommt; Chunking bestimmt, was Ihr Modell sieht. Zu kleine Chunks verlieren den Kontext, der sie sinnvoll macht; zu große holen meist irrelevanten Text neben dem relevanten Satz. Es gibt keine Universalantwort — ein paar hundert Wörter mit etwas Überlappung sind ein vernünftiger Start, und Messen schlägt Raten.

Metadaten sind Ihre Filterfläche. Speichern Sie alles, wonach Sie später eingrenzen könnten: Quelldokument, Datum, Abschnitt, Sprache, Zugriffslevel. Beim Upsert kostet das nichts; danach bedeutet es erneutes Upserten.

Namespace pro Tenant, immer, von Anfang an. Isolation nachträglich in einen Single-Namespace-Index zu bringen heißt, alles mit dem richtigen Ziel neu zu upserten. Mit Namespaces zu starten kostet einen Parameter und entfernt eine ganze Klasse künftiger Vorfälle.

Und behalten Sie den Quelltext. Legen Sie die Originaldokumente irgendwo ab, das Sie kontrollieren, zusammen mit dem Chunking-Code. Wenn Sie Embedding-Modell, Chunk-Größe oder Chunking-Strategie ändern — und das werden Sie — ist der Index-Neuaufbau ein Rerun, keine Archäologie.

Preise, geprüft

Von Pinecones eigener Preisseite, geprüft im September 2026. Vor dem Budgetieren nachprüfen.

Vier Beobachtungen, die für die Planung zählen.

Die Free-Tier ist wirklich nutzbar zur Evaluation. Zwei Gigabyte Speicher und eine Million Read Units im Monat reichen, um einen echten Prototyp über einen substantiellen Dokumentensatz zu bauen.

Builder ist ein Pauschalpreis, kein Minimum. Bei 20 $/Monat mit festen Deckelungen ist er vorhersehbar, wie die nutzungsbasierten Tarife es nicht sind — nützlich für eine kleine Produktionsanwendung, bei der Sie lieber eine planbare Rechnung haben.

Standard und Enterprise sind Minima mit Überschreitung. Die 50 $ und 500 $ sind Untergrenzen, keine Deckel. Ihre tatsächlichen Kosten sind darüber nutzungsbasiert.

Reads kosten grob das Vierfache von Writes pro Million Units. Bei 16–18 $ pro Million Read Units gegen 4–4,50 $ für Writes wird eine leselastige Anwendung — die die meisten Retrieval-Systeme sind — Queries als dominanten Posten sehen. Häufige Queries zu cachen ist deshalb ein direkter Kostenhebel, nicht nur einer für Latenz.

Enterprise ergänzt ein 99,95%-Uptime-SLA, Bring-your-own-cloud-Deployment, Private Endpoints und Audit-Logs — die übliche Menge Dinge, die in einem Beschaffungsprozess zählen und für einen Prototyp gar nichts.

Wann Sie keine verwaltete Vektordatenbank brauchen

Der Abschnitt, den ein Anbieter nicht schreiben würde, drin, weil er häufig die Antwort ist.

Wenn Ihr Corpus klein ist. Unter grob hunderttausend Vektoren ist Brute-Force-Ähnlichkeitssuche im Speicher auf gewöhnlicher Hardware schnell genug. Ein NumPy-Array und ein Skalarprodukt antworten in Millisekunden, kosten nichts und entfernen eine externe Abhängigkeit aus der Architektur. Die Schwelle, ab der Approximate Indexing nötig wird, liegt höher, als die meisten annehmen.

Wenn Sie bereits Postgres betreiben. Die Erweiterung pgvector fügt Vektor-Ähnlichkeitssuche zu einer Datenbank hinzu, die Sie schon betreiben und sichern. Für viele Anwendungen ist das die richtige Antwort: ein System weniger, transaktionale Konsistenz mit den übrigen Daten, keine separate Rechnung.

Wenn eine eingebettete Bibliothek reicht. Bibliotheken wie FAISS oder ein lokaler Vector Store bewältigen Millionen Vektoren in einem Prozess. Wenn Ihre Daten auf eine Maschine passen und das Query-Volumen bescheiden ist, löst ein Managed Service ein Operationsproblem, das Sie nicht haben.

Wenn Keyword-Suche reichen würde. Ein erheblicher Anteil von „wir brauchen semantische Suche“ wird von BM25 gut bedient: billiger, schneller, vollständig erklärbar und besser bei exakten Kennungen. Probieren Sie es zuerst — und merken Sie: landen Sie bei Pinecone, deckt dessen Volltextsuche das im selben Index ab.

Wenn Sie Retrieval-Qualität nicht gemessen haben. Die Datenbank ist selten der begrenzende Faktor in einem Retrieval-System. Chunking-Strategie, Wahl des Embedding-Modells und Query-Formulierung zählen weit mehr, und alle drei lassen sich mit hundert Zeilen lokalem Code testen, bevor eine Infrastrukturentscheidung fällt.

Der Fall für einen Managed Service ist real und konkret: viele Millionen Vektoren, Query-Volumen mit konstant niedriger Latenz, Multi-Tenant-Isolation und ein Team, das lieber keinen verteilten Index betreibt. Treffen zwei oder mehr davon zu, verdient er seine Kosten.

Häufige Fragen

Wofür wird Pinecone genutzt?

Semantische Suche, Knowledge Retrieval und Langzeitgedächtnis für KI-Anwendungen. Das dominante Muster ist Retrieval-Augmented Generation: die Passagen Ihrer eigenen Dokumente finden, die zu einer Frage am relevantesten sind, und sie einem Sprachmodell als Kontext geben.

Ist Pinecone kostenlos?

Es gibt einen kostenlosen Starter-Tarif mit bis zu 2 GB Speicher, 2M Write Units und 1M Read Units pro Monat sowie 1 GB Egress. Das reicht wirklich, um einen echten Prototyp zu bauen und zu bewerten, bevor man sich auf einen bezahlten Tarif festlegt.

Was kostet Pinecone?

Starter ist kostenlos; Builder kostet pauschal 20 $/Monat mit festen Deckelungen; Standard hat ein Nutzungsminimum von 50 $/Monat und Enterprise 500 $/Monat; beide rechnen Speicher mit 0,33 $/GB/Monat ab, Writes mit 4–4,50 $ pro Million Units und Reads mit 16–18 $ pro Million, Egress mit 0,10 $/GB nach 100 GB.

Was ist ein Namespace in Pinecone?

Eine Partition innerhalb eines Index. Jeder Lese- und Schreibvorgang zielt genau auf einen Namespace; das macht ihn zum Standardmechanismus für Multi-Tenant-Isolation — ein Namespace pro Kunde — und zu einer Performance-Optimierung, weil Queries nur die relevante Partition scannen.

Soll ich integriertes Embedding oder eigene Vektoren nutzen?

Integriertes Embedding ist einfacher: Text senden, Pinecone wandelt um. Eigene Vektoren geben Modellwahl und Portabilität, was zählt, weil ein Modellwechsel alles neu embedden erfordert. Integrierte Indexes unterstützen außerdem weder Update noch Import mit Text.

Kann Pinecone Keyword-Suche ebenso wie Vektorsuche?

Ja. String-Felder mit aktiviertem full_text_search unterstützen BM25-Ranking mit Lucene-Query-Syntax, im selben Index wie dichte und sparse Vektoren, mit pro Query gewählter Scoring-Methode. Das zählt, weil reine Vektorsuche mit exakten Kennungen und seltenen Termen schlecht umgeht.

Wie lade ich Millionen Records effizient?

Nutzen Sie Import aus Object Storage statt Upsert. Die Dokumentation empfiehlt das ausdrücklich für Datensätze über zehn Millionen Records und beschreibt es als den kostengünstigsten Weg — relevant, weil Writes pro Million Units abgerechnet werden.

Brauche ich überhaupt eine Vektordatenbank?

Oft nicht. Unter grob hunderttausend Vektoren ist Brute Force im Speicher schnell genug und kostenlos. Wenn Sie bereits Postgres betreiben, vermeidet pgvector ein separates System. Und ein fairer Anteil von „semantischer Suche“ wird von Keyword-Suche gut bedient, die billiger und erklärbarer ist.

Fazit

Pinecone ist eine verwaltete Vektordatenbank, die zu etwas Breiterem geworden ist: ein Index kann jetzt dichte Vektoren, sparse Vektoren und Volltextfelder zusammen halten, mit Ranking-Methode pro Query. Diese Konsolidierung ist die nützlichste jüngste Änderung, weil hybrides Retrieval aufhört, eine Architekturentscheidung zu sein, und ein Parameter wird.

Drei Dinge prägen, wie Sie dagegen entwerfen sollten. Namespaces sind der Isolations- und Performance-Mechanismus und entstehen implizit — ein vertippter Namespace liefert ein leeres Ergebnis statt eines Fehlers. Die Embedding-Wahl klebt stärker, als es aussieht, weil ein Modellwechsel das ganze Corpus neu embeddet. Und Reads kosten ein Mehrfaches von Writes, was Query-Caching in einem leselastigen System zum direkten Kostenhebel macht.

Die Preise sind transparent und die Free-Tier groß genug, um die eigentliche Frage zu beantworten: ob die Retrieval-Qualität für Ihren Anwendungsfall reicht. Diese Frage betrifft nicht die Datenbank — Chunking, Embedding-Wahl und Query-Formulierung dominieren sie — und sie lässt sich lokal beantworten, bevor Infrastruktur existiert.

Das ist der ehrliche Schlusspunkt. Eine verwaltete Vektordatenbank verdient ihren Platz bei Skalierung, mit Multi-Tenancy oder wenn Sie lieber keinen verteilten Index betreiben. Darunter erledigt ein Array im Speicher oder eine Erweiterung auf dem Postgres, das Sie schon laufen haben, die Arbeit umsonst — und es lohnt sich festzustellen, in welcher Lage Sie sind, bevor Sie für eines von beiden unterschreiben.