search-api-qdrant

Problem

Semantic search on a client site usually means: one vector database per project, one embedding setup, one more thing to maintain. That doesn’t scale — and most embedding APIs ship customer text to the US, which for DACH projects is a GDPR problem before the first query runs.

Approach

One platform instead of n installations: an Express core manages tenants with full per-client isolation on a shared Qdrant instance. Around it, a TypeScript SDK for custom frontends and a WordPress plugin for the most common client case. Embeddings run through a provider abstraction — six providers wired up, with a European provider as the default so the GDPR answer doesn’t depend on the client site.

Decisions

• Multi-tenant over instance-per-client. Running one platform is cheaper than maintaining ten deployments — which means isolation has to live in the architecture, not in hope.
• Provider abstraction over lock-in. Embedding models age fast; the provider is configuration, not architecture.
• Rate limiting and usage tracking from day one — part of the core, not a retrofitted feature.

Status & learnings

In development, in use for my own projects. Of my SaaS experiments this is the keeper: the problem is real, recurring, and identical in every client constellation.