AI-Powered Search Across Multi-Tenant Databases

Keyword search has a ceiling

Keyword search works when the user knows exactly what to type. An order ID, an email address, a product SKU. The search engine matches tokens and returns results. Fast, deterministic, reliable.

But users do not always search with exact terms. A support agent types "users created recently." A compliance officer searches for "payment processing issues." A customer types "overdue" when the actual field value says "past due." Keyword search returns nothing because those exact words do not appear in the data.

This gap between what the user means and what the data contains is where keyword search stops being useful. Closing that gap requires understanding intent, not just matching tokens.

What semantic search actually does

Semantic search converts text into numerical vectors, which are high-dimensional representations of meaning. Two pieces of text that mean the same thing produce vectors that are close together in vector space, even if they share no words in common.

When a query arrives, the search engine converts it into a vector and finds documents whose vectors are closest. "Overdue invoice" finds records containing "past due balance" or "late payment" because the meanings are similar, even though the words are different.

This is not new technology. What is difficult is applying it across isolated multi-tenant databases that span multiple database engines.

The multi-tenant challenge for AI search

Building semantic search for a single database is well-documented. There are vector databases, embedding APIs, and open-source frameworks designed for exactly this.

Building it for multi-tenant isolated databases introduces the same challenges as keyword search, with additional complexity on top.

Embedding at write time, not query time. Every document that enters the system needs to be converted into a vector at the moment it is written. Doing this at query time would mean vectorizing the entire dataset on every search request, which is not feasible. The indexing pipeline must generate embeddings for every write across every tenant and every database engine.

Tenant isolation in vector space. Vector similarity search typically operates on a single index. Querying a shared vector index with a tenant filter reintroduces the same isolation problem that database-per-tenant architecture was designed to eliminate. The vector index needs to be partitioned by tenant, just like the keyword index.

Multiple database engines, one vector space. A tenant might store user profiles in PostgreSQL, activity logs in MongoDB, product data in MySQL, and session metadata in Redis. All of this data needs to be embedded into the same vector space so that a single search query can find relevant results regardless of which engine stores them.

Hybrid ranking. Pure semantic search is powerful but imprecise. A search for "invoice #4821" should return the exact invoice, not semantically similar documents about invoicing. The search engine needs to combine keyword precision with semantic recall and let the application control the balance.

How hybrid search works

The most effective approach runs two search phases in parallel for every query.

The first phase is BM25 keyword matching. This is the same mechanism as traditional full-text search. It scores documents based on term frequency and inverse document frequency. Exact word matches score highest.

The second phase is vector similarity. The query is converted into a 768-dimension vector, and the engine finds documents with the closest vectors using k-nearest-neighbor search.

Both phases produce independent ranked lists. The final results are a weighted blend of both scores.

The weights are tunable per request. Different use cases require different balances.

A support agent looking up an order by ID wants keyword-heavy results. The exact token must appear. A customer using a natural language search bar wants semantic-heavy results. They are describing what they want, not typing its field value. A compliance scan wants balanced results. Specific keywords matter, but related concepts should also surface.

Multilingual search without multilingual data

One property of semantic vectors is that meaning maps across languages. The embedding model places conceptually similar text close together in vector space regardless of what language it is written in.

A query written in Spanish finds English-language records. A query in Japanese finds German-language data. The search does not translate the query. It operates entirely in vector space, where language boundaries do not exist.

This matters for SaaS applications with international customers. Your data might be stored in English, but your users search in their own language. With keyword search, you would need to maintain translated indexes or run queries in multiple languages. With semantic search in pure semantic mode, it works automatically.

Use cases for AI SaaS companies

AI-powered applications generate and process large volumes of unstructured and semi-structured data across tenants. Semantic search is particularly valuable in these scenarios.

Conversational AI platforms. Each tenant has conversation histories, user messages, and generated responses stored across databases. Semantic search lets tenants find conversations by topic or intent rather than exact phrases. "Show me conversations about refund requests" works even when users phrased their requests differently each time.

Document processing systems. Tenants upload documents that are parsed, extracted, and stored. Semantic search enables concept-level retrieval. "Find contracts with non-compete clauses" returns relevant documents even when the exact phrase "non-compete" does not appear.

Recommendation engines. Tenant-specific product catalogs, user preferences, and interaction data are scattered across databases. Semantic search can find products that match a description rather than requiring exact category or tag matches.

Knowledge management platforms. Each tenant has their own knowledge base stored in isolated databases. Semantic search enables employees to find answers by asking questions in natural language rather than guessing the right keywords.

In all of these cases, the search needs to be tenant-isolated, work across whatever database engines the tenant uses, and return results in real time.

Controlling precision and recall

The weight parameter gives your application control over the behavior of every search request.

Keyword dominant (0.8 keyword, 0.2 semantic). Use when the exact term must appear in the result. Best for IDs, email addresses, product codes, and any search where precision matters more than discovery.

Balanced (0.5 keyword, 0.5 semantic). A good starting point for most use cases. Exact matches score highly, but semantically relevant records also surface. Use this for general-purpose search bars.

Semantic dominant (0.3 keyword, 0.7 semantic). Intent and meaning matter more than exact words. Use for natural language search, concept queries, and support tools where users describe problems rather than typing field values.

Pure semantic (0.0 keyword, 1.0 semantic). Exact words have no influence on scoring. Best for cross-language queries and exploratory search where the user is browsing rather than looking for something specific.

The weights are per-request, not per-tenant. Your application can use different weights for different search interfaces within the same product.

What this costs to build yourself

Adding semantic search to a multi-tenant platform requires:

An embedding model, either self-hosted or via an API like OpenAI, Cohere, or Voyage. An indexing pipeline that generates embeddings for every write across every database engine. A vector storage layer, partitioned by tenant. A hybrid ranking system that blends keyword and semantic scores. An API that accepts weight parameters and returns merged, ranked results. Isolation guarantees that prevent cross-tenant vector similarity from leaking data.

Each of these components is a meaningful engineering project. Together, they represent months of work and ongoing operational overhead for embedding model updates, index rebalancing, and vector storage scaling.

How TenantsDB handles this

TenantsDB AI Search builds on the same indexing infrastructure as keyword search. Every write that passes through the proxy is automatically embedded and indexed into a tenant-partitioned vector space. No additional configuration, no embedding API to manage, no vector database to deploy.

Both keyword and AI search use the same API pattern. The same tenant isolation, the same cross-engine support, the same filtering by database and collection. The only difference is that AI Search understands meaning, not just tokens.

Keyword search is available on all tiers, including free. AI Search is available on paid plans.

Start free with up to 5 tenants at docs.tenantsdb.com.