All primitives

Discovery / fast retrieval

Search Engine

Help people find exactly what they’re looking for.

Understanding the concept

The idea

Imagine your application has hundreds of articles, products, or documents. How do you help people find what they need, even when they don’t remember the exact words?

A Search Engine makes your information easy to explore. It can recognize related words, handle common variations, and bring the most relevant results to the top.

For example, someone searching for “money back” could find an article about refunds, even if those exact words aren’t in the article.

Application example

Knowledge Library Search

6 text documents indexed

Search across article titles and free-form text. Results update as you type.

Query analysis

Inverted index lookup
Token: moneyToken: backSynonym: money back → refund

Each token looks up a posting list of matching documents; the lists are combined and ranked by relevance.

Search results

1 document for “money back”

Help guideUpdated 2 days ago

Refunds, returns, and order changes

How to get your money back when a purchase is canceled or returned.

For an eligible purchase, start a return request to receive a reimbursement. Once the item is received, the refund is sent to the original payment method. Bank processing times can vary.

This local example builds an in-memory inverted index over unstructured sample text. Stemming and synonyms are illustrated; production analyzers can also be configured for language, spelling, or phonetic variants.

Behind the scenes

  1. Source text
  2. Analyze and tokenize
  3. Inverted index
  4. Ranked results

An inverted index maps terms to documents, so queries can retrieve candidates without scanning every record. Stemming and synonyms can bridge word variations; phonetic matching is available in some analyzers. The original content remains the source of truth.

What could you build?

  • Documentation and knowledge libraries
  • Articles, reports, and policy archives
  • Support conversations and internal notes
  • Site-wide content discovery

A Useful Distinction

Search Engine vs. Vector Database

Imagine you’re building a movie discovery application.

Search Engine — Find something specific.

“Show me movies with Tom Hanks.”

A Search Engine is great when people know names, keywords, or specific details about what they’re looking for.

Vector Database — Find something similar to an idea.

“I want a heartwarming movie about friendship and overcoming difficulties.”

A Vector Database finds movies with similar themes and meanings, even when their descriptions use completely different words.

The best part? You can combine both approaches. Someone could search for “heartwarming Tom Hanks movies” and benefit from both.

Good for

  • Documentation and knowledge bases
  • Articles, reports, and policy archives
  • Support conversations and internal notes

Implementation notes

  • Define a search document separate from the source record.
  • Configure analyzers for the language and vocabulary people use.
  • Use stop words, stems, or synonyms where they improve relevance.
  • Return ranked results with highlights and stable source IDs.

Implementing it

With a coding agent

Ask your agent to add search

Agent setup (mock link)

Copy this prompt, fill in the bracketed details, and paste it into your coding agent. It describes the goal, the search behavior, and the guardrails.

Bracketed text marks details only you can fill in. 799 / 6,000 characters.

Fill in:CONTENT TO SEARCHAPP OR PRODUCTSEARCHABLE FIELDSFILTERSKEY RESULT DETAILSUSER, WORKSPACE, OR TENANTIMPORTANT QUERIES, FILTERS, AND ACCESS CASES

Good foundation · 72/100

Traditional SDK / API

Search an information index

TypeScript
const results = await ultrahost.search.query("articles", {
  query: "portable infrastructure",
  limit: 10,
})

Key takeaway

A Search Engine makes unstructured information findable by analyzing text, indexing terms, and ranking relevant documents.

Next primitive

Federated Auth & User Management