Add search to your app

Step by step

1. 1

   Define what "search" actually means here

   Write down which fields are searchable (title, body, tags), what users filter by (status, category, date), how results should rank, and how fresh they must be. "Search" for a 500-row admin table and "search" for a public product catalog are different projects — decide which one you're building before writing code.

2. 2

   Start with Postgres full-text search

   If you're on Postgres or Supabase, add a generated tsvector column with weighted fields plus a GIN index, and query it with websearch_to_tsquery. Ship that, put it in front of real users, and measure. Most apps never need to leave this rung.

3. 3

   Upgrade to a dedicated engine only when you hit a real wall

   When you need typo tolerance ("reciept" → "receipt"), faceted filters, or true instant-search, move the searchable data into Meilisearch or Typesense. Keep Postgres as your source of truth; the engine is just a fast, denormalized copy of the fields you search.

4. 4

   Keep the index in sync — this is the part people get wrong

   Reindex on every create, update, AND delete. Don't fire-and-forget from your request handler; use an outbox table or a queue (or a Postgres trigger + webhook) so a failed sync retries instead of silently drifting. Stale or deleted rows showing up in results is the #1 search bug.

5. 5

   Build a UI that feels instant

   Debounce the input (~150–250ms), cancel or ignore stale responses so a slow earlier request can't overwrite a newer one, highlight the matched terms, and always render explicit loading, empty, and zero-result states. Add keyboard navigation (arrow keys + Enter) — power users live in the search box.

6. 6

   Enforce access control inside the query

   Search bypasses your normal per-page authorization, so every query must filter by tenant/user/permission itself. A user searching "salary" must never surface another org's rows. Bake the ownership filter into the WHERE clause or the engine's filter, not into post-processing you might forget.

7. 7

   Add semantic/hybrid search last, if at all

   Only when keyword search visibly fails on natural-language queries, add vector search via pgvector or your engine's built-in hybrid mode. Combine keyword and vector scores rather than replacing one with the other, so exact identifiers still win.

8. 8

   Instrument and tune

   Log every query and especially zero-result searches. That log is your backlog: it tells you which synonyms to add, which ranking weights to bump, and what content users expect but you don't have.

-- Add a weighted, generated search column + GIN index (Postgres / Supabase)
alter table articles add column search tsvector
  generated always as (
    setweight(to_tsvector('english', coalesce(title, '')), 'A') ||
    setweight(to_tsvector('english', coalesce(body,  '')), 'B')
  ) stored;

create index articles_search_idx on articles using gin (search);

-- Query it. websearch_to_tsquery parses "quoted phrases" and OR like a
-- real search box. $1 is the raw user string, passed as a parameter --
-- it's data, not interpolated SQL, so there's nothing to escape.
select id, title,
       ts_rank(search, websearch_to_tsquery('english', $1)) as rank
from articles
where search @@ websearch_to_tsquery('english', $1)
  and org_id = $2              -- always scope to the caller
order by rank desc
limit 20;