Vector-DB-Kosten pro 1M Embeddings (2026)

Vector-DB-Kosten bestehen aus drei unabhängigen Komponenten. Bei Serverless-Providern werden alle drei separat berechnet; bei Cluster-basierten Providern sind Speicherung und Compute in der Cluster-Rate gebündelt:

``` monatliche_kosten = (gespeicherte_vektoren × bytes_pro_vektor / 1_000_000_000) × speicher_$/GB_monat + (monatliche_schreibvorgänge / 1_000_000) × schreib_$/M + (monatliche_abfragen / 1_000_000) × lese_$/M ```

Bytes pro Vektor = dimensionen × 4 (float32). Ein 384-dimensionaler Vektor = 1.536 Bytes. Ein 1.536-dimensionaler Vektor = 6.144 Bytes. Ein 3.072-dimensionaler Vektor = 12.288 Bytes. Dies ist die Zahl, die Teams am meisten überrascht — der Wechsel von einem 384-dimensionalen auf ein 3.072-dimensionales Embedding-Modell verachtfacht die rohen Speicherbytes, bevor Preisunterschiede überhaupt eine Rolle spielen.

Schreibvorgänge sind typischerweise einmalig oder selten (initiales Indexaufbau, periodische inkrementelle Updates). Lese-/Abfragevorgänge sind wiederkehrend — jede Benutzerabfrage ist mindestens eine Leseoperation. In der Produktion dominieren Lesevorgänge die Rechnung. Bei Pinecone Serverless sind Schreibvorgänge 25x billiger pro Einheit als Lesevorgänge ($0,33 vs $8,25 pro Million). Berechnen Sie Ihr Budget basierend auf Abfragevolumen, nicht auf Schreibvolumen.

1M Vektoren bei 1.536 Dimensionen (OpenAI text-embedding-3-small Standard) = 6,1 GB Raw-Float32-Speicher.

**Pinecone Serverless:** Speicher = 6,1 × $0,33 = **$2,01/Monat**. Schreibkosten (einmalig): 1M × $0,33/M = $0,33. Abfragekosten bei 10.000 Abfragen/Monat: 10.000 × $8,25/M = **$0,08/Monat**. Gesamt: ca. **$2,10/Monat** laufend bei niedrigem Abfragevolumen.

**Turbopuffer:** Speicher = 6,1 × $0,10 = **$0,61/Monat**. Abfragen bei 10.000/Monat: 10.000 × $0,40/M = **$0,004/Monat**. Gesamt: ca. **$0,61/Monat** — billigste gehostete Option in diesem Maßstab.

**Weaviate Cloud Standard:** $25/Mo Basis deckt den Index ab. 1M Vektoren unter der verbrauchsabhängigen Schwelle bedeutet, dass die $25/Mo Basis ausreicht. Bei niedrigem Abfragevolumen: **$25/Monat**.

**Qdrant Cloud Standard:** Einstiegs-Cluster ca. $30–60/Mo deckt einen 1M-Vektor-Index mit Spielraum ab.

**pgvector (Supabase Free/Pro):** Supabase Free beinhaltet 500 MB Postgres-Speicher; 6,1 GB überläuft zu Pro ($25/Mo Basis + $0,125/GB über 8 GB). Bei 1M Vektoren passt pgvector komfortabel auf den $25/Mo Pro-Plan. Praktisch null zusätzliche Vektor-Kosten.

Erkenntnis in diesem Maßstab: Turbopuffer ist am billigsten für speicherlastige, abfrageleichte Workloads. Pinecone Serverless ist wettbewerbsfähig. Weaviate/Qdrant-Bundles sind sinnvoll, wenn Sie verwaltete Operationen gegenüber reinen Unit-Kosten bevorzugen.

100M Vektoren bei 1.536 Dimensionen = 614 GB Raw-Float32. Dies ist ein mittleres Enterprise-RAG — eine SaaS-Wissensdatenbank, Multi-Produkt-Dokumentation, ein Finanz-Daten-Corpus.

**Pinecone Serverless:** Speicher = 614 × $0,33 = **$202,62/Monat**. Schreibvorgänge (einmalig 100M): $33 einmalig. Abfragen bei 1M/Monat: 1M × $8,25/M = **$8,25/Monat** Abfrage. Gesamt: ca. **$211/Monat**.

**Turbopuffer:** Speicher = 614 × $0,10 = **$61,40/Monat**. Abfragen bei 1M/Monat: $0,40. Gesamt: ca. **$61,80/Monat** — 3,4x billiger als Pinecone Serverless in diesem Speichermaßstab.

**Pinecone Standard pod (p1.x2):** Ein p1.x2 Pod hält ca. 250M Vektoren bei 768 Dimensionen, ungefähr gleichwertig bei 1.536 Dimensionen zu einer 125M-Vektor-Kapazität. Ca. $140–280/Monat je nach Bereitstellung. Flatrate-Vorhersehbarkeit vs Serverless-Variabilität.

**Weaviate Cloud Standard:** $25/Mo Basis + 99M Vektoren über der 1M-Basis bei $0,095/1M = **$9,41/Monat** Zusatzbetrag. Gesamt: **$34,41/Monat**, wenn innerhalb des Standard-Stufen-Compute-Budgets für Ihr Abfragevolumen — erheblich billiger als Pinecone bei dieser Vektoranzahl.

**pgvector auf verwaltetem Postgres:** 614 GB Postgres-Speicher auf Supabase ($0,125/GB über 8 GB) = ca. $76/Monat nur Speicher, keine Abfragegebühren. Erfordert Tuning von HNSW-Index-Parametern für Leistung in diesem Maßstab — überprüfen Sie `ivfflat` vs HNSW Recall-Tradeoffs vor Produktion.

Erkenntnis bei 100M Vektoren: Weaviate Cloud Standard und Turbopuffer sind die kostenkonkurrendsten verwalteten Optionen. Pinecone ist am einfachsten zu betreiben, aber kostet 3–6x mehr pro GB Speicher.

1B Vektoren bei 1.536 Dimensionen = 6.144 GB (6,1 TB) Raw-Float32. Enterprise-Scale RAG — ein vollständiges Dokumentarchiv einer Anwaltskanzlei, ein globaler E-Commerce-Produktkatalog mit Embeddings pro SKU pro Markt.

**Pinecone Serverless:** Speicher = 6.144 × $0,33 = **$2.027/Monat**. Abfragen bei 10M/Monat: 10M × $8,25/M = **$82,50/Monat**. Gesamt: ca. **$2.110/Monat**.

**Turbopuffer:** Speicher = 6.144 × $0,10 = **$614/Monat**. Abfragen bei 10M/Monat: 10M × $0,40/M = **$4/Monat**. Gesamt: ca. **$618/Monat** — ungefähr 3,4x billiger als Pinecone in diesem Maßstab.

**Zilliz Cloud dedizierter Cluster:** Bei 1B Vektoren sind dedizierte Zilliz-Tiers (Milvus verwaltet) für diese Workload konzipiert. CU-Preisgestaltung in diesem Maßstab erfordert ein benutzerdefiniertes Angebot vom Zilliz-Verkaufsteam — erwarten Sie Enterprise-Vertragspreisgestaltung anstelle von Self-Service-Raten. Überprüfen Sie bei zilliz.com/pricing oder kontaktieren Sie Vertrieb für genaue Monatszahlen.

**pgvector auf AWS RDS:** 6,1 TB Postgres-Speicher auf RDS gp3 (ca. $0,115/GB-Monat) = **$703/Monat** Speicher allein, vor Instance-Kosten. Ein db.r6g.4xlarge für HNSW-Index bei 1B Vektoren = ca. $1.100/Monat Instance. Gesamt: ca. $1.800/Monat, aber mit vollständiger SQL/Postgres-Ökosystem-Integration.

Bei 1B Vektoren ist die Reduktion der Dimensionalität enorm wichtig. Der Wechsel von 1.536 auf 768 Dimensionen (verfügbar via OpenAI Matryoshka-Trunkierung oder Voyage konfigurierbare Dimensionen) halbiert Speicherbytes — Turbopuffer fällt von $614 auf $307/Monat. Bei 384 Dimensionen: $153/Monat. Der Abruf-Qualitäts-Tradeoff muss auf Ihrem Eval-Set validiert werden — aber für die meisten Korpora verlieren 768-dimensionale Embeddings weniger als 3% recall@10 gegenüber 1.536-dimensionalen auf Standard-Benchmarks. Überprüfen Sie vor jeder Produktions-Dim-Reduktion auf Ihrem eigenen Corpus.

Die meisten Teams entdecken dies auf die harte Tour. Embedding-Modell-Dokumentation hebt Qualitätsmetriken hervor; Speicherkosten sind versteckt. Die Mathematik ist linear und unvermeidbar:

``` speicher_bytes = vektoranzahl × dim_anzahl × 4 (float32) Beispiele bei 1M Vektoren: 384 dim = 1.536 MB = 1,54 GB 768 dim = 3.072 MB = 3,07 GB 1.536 dim = 6.144 MB = 6,14 GB (OpenAI text-embedding-3-small Standard) 3.072 dim = 12.288 MB = 12,3 GB (OpenAI text-embedding-3-large Standard) ```

Bei Turbopuffer bei $0,10/GB-Monat: diese vier Optionen kosten $0,15, $0,31, $0,61 und $1,23/Monat für 1M Vektoren — der Unterschied ist in diesem Maßstab Rundungsfehler. Bei 1B Vektoren: $154, $307, $614 und $1.228/Monat — jetzt vergleichen Sie $154 vs $1.228 für die gleiche Vektoranzahl. Die 3.072-dimensionale Option kostet 8x mehr zum Speichern.

**Abhilfemaßnahmen:**

1. Nutzen Sie OpenAI text-embedding-3 Parameter `dimensions`, um eine niedrigerdimensionale Projektion anzufordern (z.B. `dimensions=768` statt Standard 3.072). OpenAI nutzt Matryoshka-Repräsentationslern — die abgeschnittenen Vektoren behalten die meisten Abfragegeräte. Ihre Docs berichten minimalen MTEB-Score-Abfall bei 1.536 Dimensionen vs 3.072 Dimensionen. Überprüfen Sie auf Ihrem eigenen Corpus vor der Produktionsfestlegung.

2. Voyage voyage-3.5 unterstützt ähnlich konfigurierbare Ausgabedimensionen.

3. Einige Vector DBs unterstützen Skalarquantisierung (int8) oder Binärquantisierung — Speicherbytes halbierend oder viertelnd auf Kosten von Recall. Pinecone, Weaviate und Qdrant bieten alle Quantisierungsoptionen. Messen Sie recall@10 vor und nach auf einem gehaltenen Abfrage-Set.

Bei Serverless-Providern wie Pinecone kosten Schreibvorgänge Geld. Bei Cluster-basierten Providern wie Weaviate oder Qdrant ist der Schreibvorgang in der monatlichen Cluster-Gebühr enthalten. Der praktische Unterschied spielt eine Rolle, wenn Sie neu indexieren.

Re-Indexierungs-Ereignisse: Ein neues Embedding-Modell wird veröffentlicht (neu einbetten + alle Vektoren neu schreiben); Chunking-Strategie ändert sich (anders aufteilen, jeden neuen Chunk einbetten, neuen Index schreiben); Metadaten-Schema-Update (einige Metadaten-Änderungen erfordern Löschen und Neu-Einfügen von Vektoren); Namespace-Reorganisation.

**Pinecone Serverless Schreibkosten für 1B Vektoren:** 1B × $0,33/1M = $330 einmalig. Für 100M Vektoren: $33. Dies sind einmalige Gebühren pro Re-Indexierung, nicht wiederkehrend — aber sie sind unsichtbar, bis Sie die Rechnung sehen. Budgetieren Sie mindestens das 1,5-fache der anfänglichen Schreibkosten pro Jahr für ein produktives System, das sich weiterentwickelt.

**Weaviate, Qdrant, Zilliz Cluster-basiert:** Re-Indexierung ist eine Compute-Kosten innerhalb des Clusters, keine inkrementelle Pro-Vektor-Gebühr. Der Cluster muss möglicherweise vorübergehend hochgefahren werden, wenn Re-Indexierung gleichzeitig mit Abfrageverarbeitung stattfindet — aber es gibt keine Pro-Schreib-Einheit-Gebühr. Dies ist ein bedeutender Vorteil für Systeme, die häufig neu indexieren.

Praktisches Muster: Führen Sie den neuen Index neben dem alten in Produktion aus (Dual-Index, A/B-Traffic-Split), validieren Sie Qualitätsmetriken, dann hart-Switch. Die temporäre doppelte Speicherkosten sind der Preis für eine sichere Migration.

pgvector ist eine PostgreSQL-Erweiterung, die native Vektor-Ähnlichkeitssuche hinzufügt. Wenn Sie bereits für eine verwaltete Postgres-Instanz zahlen (Supabase, Neon, Tembo, AWS RDS, Google Cloud SQL), kosten Vektor-Speicherung und -Suche null zusätzliche Dollar — es sind einfach Postgres-Zeilen.

**Wann pgvector die richtige Antwort ist:** Ihr Corpus beträgt unter 50M Vektoren, Sie betreiben bereits Postgres, Ihre Abfrage-Latenz-Anforderung liegt über ca. 50ms p95, und Sie möchten die Vendor-Oberfläche minimieren. Für die meisten frühen und mittleren RAG-Systeme führt pgvector mit einem HNSW-Index zu akzeptablem Latenz-Band und kostet nichts zusätzlich.

**Wann pgvector die falsche Antwort ist:** Sie liegen über 100M Vektoren und benötigen Sub-10ms-Abfrage-Latenz; Sie benötigen verteilte Vektor-Speicherung über Regionen; Sie benötigen fortgeschrittene Metadaten-Filterung zur Abfragezeit mit hoher Selektivität. An diesem Punkt verdienen spezialisierte Vector DBs (Pinecone, Weaviate, Qdrant) ihre Kostsprämie durch zweckmäßige Indexierungsstrukturen und verteilte Operationen.

pgvector HNSW-Indizes in PostgreSQL 16+ unterstützen `ef_construction` und `m` Parameter, die direkten Trade-off-Aufbauzeit und Indexgröße gegen Recall-Genauigkeit. Beginnen Sie mit den Defaults (`m=16`, `ef_construction=64`) und stimmen Sie auf Ihrem Eval-Set ab. Siehe pgvector vs Pinecone Tutorial für einen praktischen Benchmarking-Durchgang.

Die meisten RAG-Abfragen enthalten einen Metadaten-Filter: Abrufen von Vektoren, wo `user_id = X` oder `document_type = 'contract'` oder `date > 2025-01-01`. Bei spezialisiert gebauten Vector DBs kann das Kostenmodell für gefilterte vs ungefilterte Abfragen erheblich unterscheiden.

**Pinecone Serverless:** Gefilterte Abfragen können mehr Lesevorgänge als ungefilterte Abfragen auf dem gleichen Namespace verbrauchen, da die Engine mehr des Index scannen muss, um den Filter zu erfüllen. Pinecones Dokumentation beschreibt die Unit-Kosten als skalierend mit der Ergebnis-Kardinalität unter Filterung — überprüfen Sie bei docs.pinecone.io vor Budgetierung einer Workload mit hoher Filterselektivität.

**Weaviate:** unterstützt Vor-Filterung (zuerst Filter, dann ANN-Suche auf der gefilterten Untermenge) vs Nach-Filterung. Vor-Filterung ist genauer, kann aber auf hochselektiven Filtern langsamer sein. Cloud-Preis-Auswirkungen hängen von der Abfrage-Komplexität ab — überprüfen Sie im Weaviate Cloud Billing-Dashboard.

**Qdrant:** nutzt Payload-Indizierung für Metadaten-Filter; gefilterte Vektor-Suche ist eine First-Class-Operation. Leistungs- und Kostenmerkmale in großem Maßstab sollten anhand von Qdrants Benchmarks (qdrant.tech/benchmarks) für Ihre spezifische Filter-Kardinalität überprüft werden.

Fazit: Wenn Ihr RAG-Use-Case stark gefiltert ist (Mandanten-Isolation, Pro-Benutzer-Namespacing, Datums-Bereichs-Abfragen), benchmarken Sie die gefilterte Abfrage-Kosten auf Ihren tatsächlichen Datenverteilungen, bevor Sie sich an einen Provider festlegen. Gefilterte Abfrageperformance variiert zwischen Providern mehr als ungefilterte Performance.

Migration ist kostspielig (alle Vektoren neu einfügen, alle Anwendungscode auf den alten Endpunkt aktualisieren, Abfragequalität gegenüber dem neuen Index validieren). Migrieren Sie nur, wenn eine klare Schwelle überschritten wird.

**Migrieren von Serverless zu Cluster wenn:** Ihre Serverless-Lesrechnung überschreitet, was ein Cluster bei Ihrem Abfragevolumen kosten würde. Für Pinecone Serverless: bei $8,25/1M Lesevorgänge wird der p1.x1 Pod ($70-140/Mo) über ca. 8-17M Abfragen/Monat billiger. Führen Sie die Arithmetik bei Ihrem tatsächlichen Abfragevolumen durch, bevor Sie davon ausgehen, dass Serverless immer billiger ist.

**Migrieren von Cluster zu Serverless wenn:** Ihr Cluster unterausgelastet ist — Sie zahlen für einen Cluster, der für Spitzenlast dimensioniert ist, aber die Durchschnittsauslastung liegt unter 20%. Das Betriebsmodell Serverless plus das Pay-per-Query-Modell bedeutet, dass Idle-Kapazität kostenlos ist. Viele Teams kaufen dedizierte Cluster in Jahr eins über.

**Migrieren von pgvector zu spezialisiert wenn:** HNSW-Abfrage-Latenz bei Ihrer Vektoranzahl überschreitet Ihren SLA bei p95, oder Sie benötigen Multi-Region-Replikation, oder Ihre Metadaten-Filterungs-Komplexität übersteigt, was Postgres Query Planning effizient handhabt. Typischer Auslöser: 50-100M+ Vektoren mit Sub-15ms-Latenz-Anforderungen.

Für einen detaillierten Vergleich der Datenbanken und ihrer architektonischen Tradeoffs siehe Pinecone vs Weaviate vs Qdrant und unser RAG-Architektur-Entscheidungsbaum.

Erstellen Sie diese Tabelle, bevor Sie sich an einen Vector DB festlegen. Vier Zahlen treiben 95% der Monatsrechnung:

``` 1. vektoranzahl — aktuelle Corpus-Größe, nicht projiziertes Maximum 2. dim_anzahl — aus Ihrem gewählten Embedding-Modell 3. monatliche_abfragen — aus Ihrem tatsächlichen oder geschätzten Abfragevolumen 4. monatliche_schreibrate — Vektoren hinzugefügt/aktualisiert pro Monat (inkrementelle Index-Updates) monatlich_speicher_GB = vektoranzahl × dim_anzahl × 4 / 1_000_000_000 Pinecone Serverless: monatlich = (speicher_GB × 0,33) + (monatliche_abfragen / 1_000_000 × 8,25) + (monatliche_schreibvorgänge / 1_000_000 × 0,33) Turbopuffer: monatlich = (speicher_GB × 0,10) + (monatliche_abfragen / 1_000_000 × 0,40) Weaviate Cloud Standard: monatlich = 25 + max(0, (vektoranzahl - 1_000_000) / 1_000_000 × 0,095) ```

Die Formel macht eines offensichtlich: Bei hohen Vektoranzahlen mit niedrigem Abfragevolumen schlagen Turbopuffer und Weaviate Pinecone Serverless bei Speicherkosten. Bei hohem Abfragevolumen mit niedriger Vektoranzahl ist Pinecone Serverless kostenkonkurrenzfähig, weil Sie nur für das zahlen, was Sie abfragen.

Für den LLM-Aufruf, der nach dem Abruf stattfindet — der typischerweise die Gesamt-RAG-Rechnung dominiert — siehe den RAG-Kostenrechner pro Abfrage.