What is full-text and faceted search?
Full-text search goes beyond a simple database LIKE query. It understands relevance — a search for "invoic" still finds "invoice" (typo tolerance), and results are ranked by how well they match rather than returned in insertion order. Users get results that feel intelligent, not just technically correct.
Faceted search adds the ability to filter results along multiple dimensions simultaneously — by category, price range, location, rating, and availability all at once. Each active filter narrows the result set, and the facet counts update to show how many results remain in each bucket. This is the search experience users expect from marketplaces, directories, and e-commerce platforms.
Note: this is distinct from AI semantic search (finding conceptually related content) — that's a separate feature with different infrastructure.
When does your app need it?
- Users are searching a catalogue with hundreds or thousands of records — products, listings, jobs, articles
- Simple database queries are producing irrelevant results or missing obvious matches
- Users need to filter on multiple attributes at the same time (price + category + location)
- You want autocomplete / instant search as users type
- Your app is a marketplace, directory, or content platform where search is the primary discovery mechanism
- Query performance is suffering as your data volume grows
How much does it cost?
Adding full-text and faceted search typically adds 5–11 hours of development — roughly $1,000–$2,000 AUD.
Lower end: PostgreSQL full-text search using tsvector and tsquery. Free, no additional infrastructure, and genuinely capable for smaller datasets and moderate query complexity. Good choice if you're already on Postgres and the dataset fits comfortably in a single table.
Higher end: A dedicated search service (Algolia, Meilisearch, Typesense) with an indexing pipeline that keeps the search index in sync with your database, autocomplete/instant search on the frontend, faceted navigation UI, and custom ranking rules. Algolia is the most fully featured and easiest to integrate but has significant per-search cost at scale; Meilisearch is open-source and self-hostable.
How it's typically built
The core pattern: your database is the source of truth; the search index is a copy optimised for querying. When a record is created, updated, or deleted, you update the search index — either synchronously in the same request, or via a background job.
With Algolia or Typesense, you configure the fields to search, the facets to filter by, and the ranking rules, then call their API from your frontend. The search UI (instant results, highlighting, facet panels) is handled by their front-end libraries.
With PostgreSQL full-text search, you define tsvector columns, index them with GIN, and write queries using to_tsquery. This requires more SQL expertise but eliminates third-party dependency and per-query cost.
Questions to ask your developer
- How many records are being searched? Under 100,000 records, PostgreSQL full-text search is often sufficient. Above that, a dedicated service earns its keep.
- Do you need faceted filtering? Simple keyword search vs filtered browsing are different levels of implementation complexity.
- How fresh do search results need to be? Real-time index sync (synchronous) is simpler but adds latency; background sync is faster but results may lag seconds behind the database.
- What's the cost model for a managed search service? Algolia charges per operation — model the expected query volume at your target scale.
- Does the search need to handle multiple languages or Australian English quirks? Analyser configuration (stemming, stop words) matters for relevance quality.
See also: Content management CMS · Public API and webhooks · App cost calculator