Multi-tenancy

Patterns for SaaS apps that need per-customer search isolation.

If you're building a SaaS where each of your customers needs their own search index, you have two options.

# Pattern A: One Skryx tenant per Skryx account (just you)

You create a single Skryx tenant. Inside it, you put a tenant_id (or customer_id, workspace_id) field on every document and pass filter_by: "tenant_id:42" on every query.

Pros:

  • Operationally simple — one account, one billing line.
  • All your customers share one index → 1 search bar, N tenants = N filtered queries.
  • Cheap.

Cons:

  • You have to remember to filter every query (a SaaS bug here is bad — never trust the user's input for tenant_id).
  • One noisy customer can affect aggregate latency if it's huge.

# Pattern B: One Skryx tenant per your customer

You programmatically create a Skryx tenant per customer and issue them their own API key. Each customer's search is fully isolated at the engine level.

Pros:

  • Hard isolation — no risk of cross-tenant data leakage in your code.
  • Per-customer settings, synonyms and ranking rules.

Cons:

  • More moving parts. You manage tenant lifecycle from your side.
  • Requires a partner-level account; talk to us before going this route.

For most SaaS apps, Pattern A is the right default. The filter discipline is the same as any multi-tenant Postgres query, and Skryx scopes API keys to specific query_by allowlists if you want defence in depth.

esc