TenantsDB Search indexes every write that passes through the proxy and makes it instantly queryable. A single request hits PostgreSQL tables, MySQL tables, MongoDB collections, and Redis hashes at the same time, returning ranked results from all of them in one response.

Tenant isolation is not a query-time check. Each tenant's data is written into its own partitioned namespace at index time. There is no filter that could be misconfigured or bypassed. When a tenant searches, the engine physically only has access to their namespace.

Your application does not change. No SDK to add, no index to maintain, no sync job to run. Every INSERT, UPDATE, or document write is picked up automatically.

# Write a row (OQL or native SQL - does not matter)
$ tdb query --tenant demo --blueprint App1 \
    --query ':CREATE User WITH name:"OQLTest1", email:"[email protected]"'

# Search for it immediately - no delay, no setup
$ tdb search --tenant demo --query "OQLTest1"

DATABASE    COLLECTION  ID  SCORE  CREATED       CONTENT
PostgreSQL  users       50  3.093  Mar 05 00:15  email: [email protected] | name: OQLTest1
1 results in 112ms

Most search solutions assume a single data source - one database, one schema, one tenant. Scaling that to multi-tenant means writing an indexing pipeline per database type, partitioning the index per tenant, keeping everything in sync as schemas evolve, and making sure no tenant's query ever touches another's data. That is a significant engineering project on its own.

TenantsDB Search solves all of that as a single primitive. Because TenantsDB sits between your application and every database, it sees every write across every tenant and every database type. The indexer uses that position to build a unified, tenant-partitioned search index automatically.

TenantsDB runs an internal indexer that subscribes to the message bus. Every time a write completes through the proxy, the indexer receives the event and indexes the affected rows or documents into a tenant-partitioned namespace. By the time your application could issue a search, the data is already there.

When a write is indexed, it is written into a namespace derived from your project ID and the tenant ID. The namespace is immutable and tied to the data at the moment of indexing. When a search query arrives for tenant acme, the engine resolves the namespace for acme and only that namespace is queried. There is no filter that runs at query time that could be misconfigured, bypassed, or accidentally omitted.

Each result includes a score field. Scores are floating-point relevance values computed using TF-IDF weighting: how often the term appears in the document versus how rare the term is across all documents in the namespace. Results are returned sorted by score descending.

Scores are not normalized to a fixed range. A score around 3.0 is typical for a strong single-field match. Use scores to rank results, not as an absolute threshold.

Both databases and collections filters are applied inside the search engine at query time, reducing scope before scoring runs. Filtered searches are faster and return tighter results.

# Search only PostgreSQL and MongoDB, skip MySQL and Redis
$ tdb search --tenant acme --query "Alice" --databases PostgreSQL,MongoDB

# Search only the invoices and orders tables
$ tdb search --tenant acme --query "overdue" --collections invoices,orders

# Combine both filters
$ tdb search --tenant acme --query "overdue" \
    --databases PostgreSQL \
    --collections invoices,orders