search-api-qdrant

Problem

Semantische Suche auf einer Kundenseite heißt normalerweise: pro Projekt eine eigene Vektor-Datenbank, ein eigenes Embedding-Setup, eigene Pflege. Das skaliert nicht — und die meisten Embedding-APIs schicken Kundentexte in die USA, was für DACH-Projekte ein DSGVO-Problem ist, bevor die erste Suchanfrage läuft.

Ansatz

Eine Plattform statt n Installationen: ein Express-Core verwaltet Tenants mit vollständiger Per-Client-Isolation auf einer gemeinsamen Qdrant-Instanz. Drumherum ein TypeScript-SDK für eigene Frontends und ein WordPress-Plugin für den häufigsten Kundenfall. Embeddings laufen über eine Provider-Abstraktion — sechs Provider angebunden, als Default ein europäischer Anbieter, damit die DSGVO-Antwort nicht von der Kundenseite abhängt.

Entscheidungen

• Multi-Tenant statt Instanz pro Kunde. Eine Plattform zu betreiben ist billiger als zehn Deployments zu pflegen — die Isolation muss dafür in der Architektur sitzen, nicht in der Hoffnung.
• Provider-Abstraktion statt Lock-in. Embedding-Modelle altern schnell; der Provider ist Konfiguration, nicht Architektur.
• Rate-Limiting und Usage-Tracking von Anfang an — nicht als nachgerüstetes Feature, sondern als Teil des Kerns.

Status & Learnings

In Entwicklung, im Einsatz für eigene Projekte. Von den eigenen SaaS-Experimenten ist das der Keeper: das Problem ist real, wiederkehrend und in jeder Kundenkonstellation dasselbe.