Multi-tenant in-app search with open source engines

Which isolation requirements shape a multi-tenant search build

This table maps each isolation requirement to its likely source, whether customer contracts, your own security policy or an engine capability, and to the design choice it pushes toward. Read it before picking tokens, keys, indexes or document-level security, because a single requirement such as per-tenant deletion or data location can rule out an option early.

Tenant tokens, scoped keys or per-tenant indexes: how each pattern isolates data

Which open source engine fits which tenant model

Each engine isolates tenants in a different way, and the right choice depends on how many tenants you serve and how strictly results must follow each user's permissions. The cards below cover the three engines and the index design decision that sits underneath them.

How much RAM a multi-tenant index needs

Building the indexing pipeline from the application database

The sequence below moves tenant data from the application database into a search engine in a way that keeps every document traceable to one tenant, stays current after edits, and can be rebuilt without guessing. Each step produces a artifact that the next one depends on.

1. Map the tenant model and document shape

   Before any code runs, the engineering team lists which tables hold searchable content, how each record links to a tenant, and which fields users may see under each role. The output is a documented index schema: one document per searchable entity, a mandatory tenant identifier on every document, filterable and sortable attributes declared up front, and a list of fields excluded from the index. Ask the implementation partner to show this schema in writing and to confirm that a missing tenant identifier fails the write rather than creating an untenanted document.

2. Capture changes from the source database

   The pipeline needs a reliable record of inserts, updates and deletes in the application database. Common options are an outbox table written in the same transaction as the business change, or change data capture that reads the database log. Either way, each change event carries the tenant identifier and an entity identifier. The step is complete when a test edit in a staging tenant appears as an ordered event that the indexer can replay, and when the team has confirmed how the chosen method behaves during database failover.

3. Backfill existing records in batches

   Existing data has to be loaded before live changes matter. The backfill reads each tenant's records in pages, transforms them with the same code path as live events, and imports them in batches sized to the engine's documented import method. Run the backfill against a copy of production data first to measure memory use and import time on the target engine, since index size drives RAM needs. The step is complete when record counts per tenant in the database match counts in the index, and a sample of documents has been checked field by field.

4. Write tenant-tagged documents

   The indexer applies each change event as an upsert keyed on the entity identifier and writes the tenant identifier as a filterable attribute, or routes the document to a per-tenant index if that design was chosen. Permission data, such as role or group identifiers that determine visibility, is written with the document or resolved at query time, and the choice is recorded in the schema. The step is complete when a test user in one tenant cannot retrieve a document from another tenant through any search parameter, including empty queries and pagination.

5. Handle deletes and tenant offboarding

   Deleting a single record must remove its document, and that removal must be replayed if the indexer is down. Offboarding a whole tenant needs its own procedure: delete by tenant filter for shared indexes, or drop the tenant index for per-tenant designs, plus removal of its API keys and backups according to the retention policy. The output is a written offboarding runbook with a check that confirms zero documents remain for that tenant identifier. Confirm with the vendor how deletes by filter are performed and whether they are asynchronous.

6. Run reconciliation jobs

   Event streams miss things, so a scheduled job compares source and index for each tenant, looking for missing documents, stale versions and orphaned documents whose source record was deleted. Discrepancies are either repaired by re-indexing the affected records or logged for review. The step is complete when the reconciliation report can be produced on demand and the team has tested it by deliberately removing a document from the index and confirming the job restores it.

7. Document and test the reindex procedure

   The last step turns the pipeline into something operations can run without the original builders. The team writes the full reindex procedure: how to build a new index version alongside the live one, how to switch traffic, how to roll back, and how to rerun the backfill for a single tenant. The procedure is tested in a non-production environment and the result is recorded. The deliverable is the schema document, the offboarding runbook and the tested reindex procedure, handed over with the source code and configuration.

Integration points and deployment patterns for SaaS search

A multi-tenant search feature touches four places: the request path through your API, the process that writes records into the index, the cluster itself, and the logs that prove who searched what. Each one needs a named owner for tenant tagging, because a single missed filter at any point exposes another customer's records.

Evidence a SaaS customer or auditor will ask for

This table lists the evidence a SaaS customer, their security team or an external assessor is likely to request for in-app search, and the component that produces each item. Use it to decide which logs, configuration exports and test records to design in from the start. DeployOpen prepares this evidence for your own assessor and does not issue attestations or audit reports.

Questions SaaS teams ask before adding multi-tenant search

Questions to ask an implementation partner on tenant isolation

Rolling out tenant-scoped search in phases

The rollout moves from tenant data mapping to a production cutover in stages, so each isolation decision is tested with synthetic tenants and a limited customer group before every customer depends on search. Each phase ends with a written output that the next phase relies on.

1. Map tenant data models and access rules

   DeployOpen works with your engineering and security leads to document how tenants, users, roles and resource permissions are stored in the application database, including shared tables, shared schemas and any customer-specific fields. The team also records which documents must be filtered by tenant, which must be filtered by role within a tenant, and which can be shared. This phase closes with a signed data map and a list of permission rules the search layer must reproduce, so the design is agreed before any engine is configured.

2. Select engine and size the deployment

   The team chooses between Meilisearch, Typesense and OpenSearch using the tenancy model from the first phase, the expected number of tenants and documents, and your uptime requirements. Sizing is calculated from the searchable field volume, the number of vectors if semantic results are planned, and the availability design. Typesense keyword search typically needs 2 to 3 times the size of the searchable fields in RAM, so memory is estimated from your own field sizes, not a generic figure. The output is a written engine decision, a sizing worksheet and a hosting plan inside your cloud account or data center.

3. Build the tenant isolation and indexing pipeline

   DeployOpen implements the chosen isolation method, whether tenant tokens, scoped API keys or per-tenant indexes, and builds the indexing pipeline that reads from the application database and writes documents with a tenant identifier. The pipeline covers initial bulk loads, incremental updates on record change, deletions and re-indexing after schema changes. Key scopes and index naming are documented in code and configuration. The phase is complete when a full load and an incremental change both reach the search index in a repeatable run.

4. Test isolation with synthetic tenants

   Before any real customer data is indexed, the team creates synthetic tenants with overlapping record names, mixed roles and deliberately restricted documents. Test cases attempt cross-tenant queries, expired or altered tokens, filter bypass through query parameters and role changes that should remove access immediately. Results are logged and any leak is fixed and retested. The output is a test report covering each isolation method and permission rule from the data map, which your security team can review before the pilot starts.

5. Run a pilot with a limited customer group

   A small, agreed group of customers is switched to the new search, with the existing search kept available as a fallback. The team monitors query latency, zero-result rates, indexing lag and any support tickets about missing or extra results. Your product team confirms relevance on real queries, and the pilot list of metrics is agreed beforehand. The phase closes with a pilot report that states which issues were found, which were fixed and whether the build is ready for general release.

6. Cut over to production with a tested rollback

   The production cutover follows a written runbook that sets the switch order, the reindex steps, the monitoring checks and the criteria for reverting to the previous search. The rollback path is rehearsed before cutover, including restoring the prior index or routing traffic back to the fallback. Backups and snapshots are confirmed on the new cluster. The phase is complete when all tenants are on the new search, the monitoring is handed to your operations team, and the rollback has been tested in a non-production environment.