Vektordatenbank Kosten: Wofür Sie tatsächlich bezahlen

Die Kosten einer Vektordatenbank ergeben sich aus vier Stellschrauben: wie viele Vektoren Sie speichern, wie viele Dimensionen jeder Vektor hat, wie viele Abfragen Sie bedienen und wie viele Replikate Sie betreiben. Dazu kommen Kosten, die auf keiner Datenbankrechnung auftauchen, vor allem das Erzeugen der Embeddings und die komplette Neuindexierung bei jedem Modellwechsel. Dieser Beitrag erklärt jeden Kostentreiber, zeigt eine Überschlagsrechnung für den Speicherbedarf und hilft Ihnen bei der Frage, ob Sie überhaupt eine eigene Vektordatenbank brauchen.

Was in einer Vektordatenbank eigentlich liegt

Eine Vektordatenbank speichert Embeddings, also Zahlenreihen, die die Bedeutung eines Textabschnitts abbilden. Jedes Dokument wird in Abschnitte (Chunks) zerlegt, und jeder Abschnitt erhält einen eigenen Vektor. Wenn Ihnen das Prinzip noch nicht vertraut ist, lesen Sie zuerst Was ist eine Vektordatenbank? und kehren Sie dann für die Kostenseite hierher zurück.

Für das Budget heißt das: Sie zahlen nicht pro Dokument, sondern pro Vektor. Ein 50-seitiges PDF kann 50 oder 500 Vektoren ergeben, je nach Chunk-Größe und Überlappung. Diese eine Entscheidung, die viele Teams einmal treffen und dann vergessen, kann die Kosten um eine Größenordnung verschieben.

Die vier Kostentreiber

Ob Sie eine Open-Source-Engine selbst betreiben, PostgreSQL um eine Erweiterung ergänzen oder einen Managed Service nutzen: Darunter liegen immer dieselben Ressourcen. Anbieter rechnen sie unterschiedlich ab (pro Stunde, pro Gigabyte, pro Lese-Einheit), doch die Hebel bleiben gleich.

1. Anzahl der Vektoren

Zählen Sie Chunks, nicht Dateien, und planen Sie Wachstum ein. Verdoppelt sich Ihr Dokumentenbestand innerhalb eines Jahres, verdoppelt sich auch der Index.

2. Dimensionen und Genauigkeit

Das Embedding-Modell legt die Dimension fest; 384, 768, 1.024, 1.536 und 3.072 sind gängige Werte. Als float32 belegt jede Dimension 4 Byte. Ein Vektor mit 1.536 Dimensionen braucht also rund 6 KB, noch ohne Index.

3. Abfragevolumen und Latenz

Indexe für die näherungsweise Nächste-Nachbarn-Suche, etwa HNSW-Graphen aus der ursprünglichen Veröffentlichung, sind schnell, weil sie einen Graphen durchlaufen statt alles zu vergleichen. Dafür muss der Graph in aller Regel im Arbeitsspeicher liegen. Mehr Abfragen pro Sekunde, strengere Latenzziele und Metadatenfilter verlangen mehr RAM und CPU.

4. Replikate, Umgebungen und Mandanten

Für Ausfallsicherheit laufen produktive Indexe meist auf zwei oder drei Replikaten, jedes mit vollständiger Kopie. Kommen eine Testumgebung und vielleicht ein eigener Index pro Kunde hinzu, bezahlen Sie dieselben Vektoren mehrfach.

Speicherbedarf der Embeddings überschlagen

Für eine erste Schätzung brauchen Sie keine Preisliste. Die Formel lautet: Anzahl Vektoren × Dimensionen × 4 Byte (float32). Die folgenden Werte sind Rohgrößen ohne Index, Metadaten und Replikate.

Rechenbeispiel: 1.000.000 × 1.536 × 4 = 6.144.000.000 Byte, also rund 6,1 GB. Hinzu kommen die Nachbarschaftslinks des Graphen, der gespeicherte Chunk-Text und die Metadaten, und das Ganze mal Anzahl der Replikate. Aus scheinbar 6 GB werden so schnell mehrere Dutzend Gigabyte RAM im Cluster.

Versteckte Kosten: Embeddings, Neuindexierung, Personal

• Embeddings erzeugen. Jeder Chunk läuft beim Import durch ein Embedding-Modell, jede Frage wird bei der Suche vektorisiert. Ob per API oder auf eigenen GPUs: Das kostet laufend.
• Neuindexierung beim Modellwechsel. Vektoren aus verschiedenen Modellen sind nicht vergleichbar. Ein Wechsel des Modells oder der Dimension heißt: alles neu berechnen und den Index neu aufbauen, meist während der alte noch produktiv läuft.
• Neues Chunking. Sind die Antworten schwach und Sie ändern die Zerlegung, wird erneut alles vektorisiert. In den ersten Monaten passiert das oft mehrfach.
• Aktualisierungen und Löschungen. Die Synchronisation mit den Quelldokumenten braucht eine Pipeline; manche Indexe verschlechtern sich nach vielen Löschungen, bis sie neu gebaut werden.
• Backups und Datentransfer. Snapshots und Kopien zwischen Regionen kosten Speicher und Egress.
• Betrieb. Parameter-Tuning, Qualitätsmonitoring, Updates und Bereitschaft brauchen eine verantwortliche Person.

Auch Compliance kostet. Nach DSGVO sollten Embeddings, die aus Texten mit personenbezogenen Daten berechnet und neben diesen Texten gespeichert werden, wie personenbezogene Daten behandelt werden: Zugriffskontrolle, Löschfristen, Verzeichnis der Verarbeitungstätigkeiten, Speicherort. Für den Mittelstand kommen häufig Anforderungen an Informationssicherheit nach den Empfehlungen des BSI hinzu, und der AI Act ergänzt je nach Einsatzzweck eigene Pflichten.

Selbst betreiben oder Managed Service?

Beim Selbstbetrieb zahlen Sie keine Lizenz, aber Server, Speicher, Monitoring und vor allem Arbeitszeit. Ein Index, der im RAM liegen muss, verlangt Maschinen mit viel Arbeitsspeicher, und zwar für jedes Replikat. Updates der Engine, Sicherheits-Patches und das Wiederherstellen nach einem Ausfall übernimmt Ihr eigenes Team. Für ein Unternehmen mit erfahrener Datenbank-Administration kann das günstig sein; für ein kleines Team ohne Bereitschaftsdienst wird es schnell teuer.

Ein Managed Service verlagert diese Arbeit zum Anbieter, rechnet dafür aber nach eigenen Einheiten ab. Prüfen Sie deshalb genau, was eine Einheit enthält: Zählt ein Lesevorgang pro Abfrage oder pro zurückgegebenem Treffer? Sind Metadatenfilter teurer? Wird ein Mindestbetrag pro Monat fällig, auch wenn kaum jemand sucht? Rechnen Sie jedes Angebot auf Ihre eigenen Zahlen aus der Überschlagsrechnung oben zurück, dann werden die Unterschiede sichtbar.

Wann Sie keine Vektordatenbank brauchen

• Kleiner Bestand. Einige tausend Chunks passen problemlos in den Speicher, und ein vollständiger Vergleich ist schnell genug.
• Fragen nach exakten Begriffen. Paragrafen, Artikelnummern, Fehlercodes und Namen findet eine Volltextsuche oft besser als reine semantische Ähnlichkeit. Hybride Suche aus Stichwörtern und Bedeutung schlägt Vektoren allein häufig.
• PostgreSQL ist schon im Einsatz. Eine Vektor-Erweiterung hält Embeddings neben Ihren relationalen Daten, mit einem Backup- und Rechtekonzept.
• Sie wollen Antworten, keine Infrastruktur. Sollen Mitarbeitende oder KI-Assistenten Dokumente abfragen, nimmt Ihnen ein Managed Service Datenbank, Embedding-Pipeline und Neuindexierung ab.

Genau das ist RAG as a Service. Bei Kopik legen Sie kostenlos eine Wissensbasis an, indem Sie PDF-, Word-, Text- oder Markdown-Dateien hochladen; Kopik extrahiert, zerlegt und indexiert sie für eine hybride Suche (Volltext plus semantische Erweiterung der Suchbegriffe). Kein Cluster, keine Dimensionen: Fragen bezahlen Sie mit Prepaid-Guthaben oder über das Chat-Abo für 12 € im Monat mit Verbrauchsanzeige. Wie eine Frage durch eine solche Pipeline läuft, zeigt Wie funktioniert RAG?.

Checkliste vor dem Anbietervergleich

1. Chunks heute zählen und für die nächsten 12 Monate hochrechnen.
2. Embedding-Dimension wählen und Vektoren × Dimensionen × 4 Byte berechnen.
3. Quantisierung mit 50-100 echten Fragen testen.
4. Anzahl der Replikate und Umgebungen festlegen (Produktion, Test, pro Mandant).
5. Abfragen pro Tag und Spitzenlast pro Sekunde schätzen, inklusive KI-Agenten, die mehrfach suchen.
6. Embedding-Kosten für Erstimport, laufende Updates und mindestens eine vollständige Neuindexierung pro Jahr einplanen.
7. Speicherort (EU oder nicht), Verschlüsselung und Protokollierung je Tarif prüfen.
8. Den Zeitaufwand Ihres Teams für Betrieb und Wartung beziffern.