Search for Builders

A SQL LIKE query does substring matching — it scans every row looking for the exact string you provide, making it slow and inflexible. Full-text search works by pre-processing text into indexed tokens (removing stopwords, stemming "running" to "run"), which enables fast matching, relevance ranking, and language-aware searching. PostgreSQL's full-text search uses tsvector documents (pre-processed text) and tsquery expressions (search terms), indexed with GIN for performance. The result is faster queries, better relevance ranking, and support for natural language variations.

Use Postgres FTS when: your dataset is small to medium (under 100k documents), you want to avoid additional infrastructure, and your search requirements are modest. Use Typesense when: you need typo tolerance, faceted filtering, geosearch, or instant-search speed, and you are comfortable self-hosting via Docker. Use Algolia when: you want a fully managed service with zero infrastructure management, are building an e-commerce or content site with heavy search requirements, or need their advanced UI component library. Typesense and Algolia have similar capabilities; the choice is usually managed vs self-hosted.

Typo tolerance means returning relevant results even when users misspell their query. A user searching for "recieve" should find results for "receive". Standard SQL queries and basic full-text search do not handle this — they match text exactly. Dedicated search engines like Typesense and Algolia calculate edit distance between the query and indexed terms, allowing matches that are one or two characters different. This dramatically improves search quality, particularly on mobile where typing errors are common.

Faceted search lets users filter results by multiple categories simultaneously — the way Amazon lets you filter by brand, price range, rating, and delivery time at the same time, with counts updating for each combination. Implementing faceted search with SQL requires complex GROUP BY queries that become slow as data grows. Dedicated search engines maintain pre-computed facet counts in their index, returning filters and counts in a single fast query. Typesense and Algolia both have native faceting support that renders in React with their UI component libraries.

Search indexes are a denormalised copy of your database data, so they need to be updated when the source data changes. The three main patterns are: 1) Synchronous indexing — call the search API immediately after writing to the database in the same request (simple but adds latency and risks partial failures). 2) Webhook/event-driven indexing — trigger index updates from database webhooks or Supabase Realtime events. 3) Background job indexing — queue index update jobs via BullMQ or similar after each write. For most applications, synchronous indexing with retry logic is sufficient to start.