pgvector vs. Pinecone: Warum wir PostgreSQL für Agent Memory nutzen

Jedes AI-System braucht ein Gedächtnis. Ohne Gedächtnis ist dein Agent wie ein Praktikant am ersten Tag. Jeden Tag. Er weiss nichts über dein Unternehmen. Nichts über deine Kunden. Nichts über letzte Woche.

Die Frage ist nicht ob dein Agent ein Gedächtnis braucht. Die Frage ist: Wo speicherst du es?

Wir haben uns für pgvector entschieden. PostgreSQL. Keine separate Datenbank. Kein Drittanbieter. Kein US-Cloud-Service. Hier ist warum.

Was Vector Databases machen

Dein Agent liest Text. Ein Kundengespräch. Eine E-Mail. Ein Dokument. Dieser Text wird in einen Embedding umgewandelt — eine mathematische Darstellung des Inhalts. Statt Wörter speicherst du Zahlen. Einen Vektor mit 384 Dimensionen.

Warum? Weil du dann semantisch suchen kannst. Klassische Suche: Du tippst "Rechnung" und findest alles mit dem Wort "Rechnung". Vector-Suche: Du tippst "offene Zahlungen" und findest auch Dokumente über "ausstehende Fakturen" oder "unbezahlte Invoices". Weil die Bedeutung ähnlich ist.

Die Optionen auf dem Markt

Pinecone

Der Marktführer. Cloud-basiert. Gehostet in den USA. Funktioniert gut. Skaliert gut. Kostet Geld. Du zahlst pro Query. Du schickst deine Daten an einen US-Server. Für ein Schweizer KMU mit sensiblen Geschäftsdaten ist das ein Problem.

Weaviate

Open Source. Mächtig. Komplex. Du brauchst einen separaten Service, einen separaten Server, separates Monitoring. Für ein KMU — Overkill.

Chroma

Leichtgewichtig. Embedded. Python-native. Perfekt für Prototypen. Aber: Chroma skaliert begrenzt. Keine native SQL-Integration.

pgvector

Eine PostgreSQL-Extension. Kein neues System. Kein neuer Service. Eine Zeile SQL:

CREATE EXTENSION vector;

Fertig. Deine bestehende PostgreSQL-Datenbank kann jetzt Vektoren speichern und durchsuchen. Gleiche Datenbank. Gleiche Backups. Gleiche Zugriffsrechte.

Warum KaderOS pgvector nutzt

1. Kein separater Service nötig

Jeder neue Service in deiner Infrastruktur ist ein weiterer Punkt, der ausfallen kann. pgvector läuft in deiner bestehenden PostgreSQL-Datenbank. Kein neuer Container. Kein neuer Port.

2. Supabase hat pgvector eingebaut

KaderOS läuft auf Supabase. Supabase nutzt PostgreSQL. pgvector ist standardmässig verfügbar. Zero Setup.

3. Deine Daten bleiben bei dir

Pinecone-Server stehen in den USA. Deine Embeddings liegen auf fremden Servern. Mit pgvector bleiben deine Daten dort, wo deine Datenbank ist.

4. SQL + Vector in einer Datenbank

Mit Pinecone hast du zwei Systeme. Zwischen den beiden musst du synchronisieren. Mit pgvector? Eine Query:

SELECT 
  documents.title,
  documents.content,
  1 - (documents.embedding <=> query_embedding) AS similarity
FROM documents
WHERE documents.project_id = 'xyz'
ORDER BY documents.embedding <=> query_embedding
LIMIT 5;

SQL-Filter und Vector-Suche in einer Query. Keine Sync-Probleme.

5. Keine API-Kosten pro Query

Pinecone kostet. Pro gespeichertem Vektor. Pro Query. Pro Monat. pgvector kostet nichts. Es ist eine Open-Source-Extension.

Technische Details

Embedding-Modell: sentence-transformers (all-MiniLM-L6-v2). 384 Dimensionen. Läuft lokal. Keine externe API.

Similarity-Metrik: Cosine Similarity. Standard für Textsuche.

Index-Typ: IVFFlat oder HNSW — je nach Datenmenge.

CREATE TABLE memories (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  agent_id UUID REFERENCES agents(id),
  content TEXT NOT NULL,
  embedding VECTOR(384),
  memory_type TEXT CHECK (memory_type IN ('conversation', 'document', 'decision')),
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX ON memories 
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

Keine externe Dependency. Keine API-Keys. Keine Rate Limits.

Vergleichstabelle

Wann Pinecone trotzdem Sinn macht

Ehrlichkeit gehört dazu. Pinecone ist nicht schlecht. Es ist falsch für unseren Use Case.

Wenn du Millionen von Vektoren speicherst und globale Verfügbarkeit brauchst — Pinecone. Wenn du ein Enterprise-Team mit eigenem DevOps hast — Pinecone. Wenn nDSG kein Thema ist — Pinecone.

Für alles andere: pgvector.

Das Ergebnis

KaderOS speichert Agent Memory in der gleichen Datenbank wie alles andere. Benutzer, Projekte, Kader, Budgets, Entscheidungen — und Gedächtnis. Alles an einem Ort.

Kein Vendor Lock-in. Keine Überraschungskosten. Keine Daten in den USA.