When to Reach for a Dedicated Search Engine

This is this course's own central chapter — where nine chapters of architecture, indexing, querying, scoring, aggregations, and distribution stop being separate facts and become one honest, usable decision framework, directly answering the question postgres1-6 deliberately left open.

When Postgres's Own Full-Text Search Is Enough

postgres1-6's own guidance remains accurate, and this chapter isn't here to overturn it: Postgres's own built-in full-text search is the right choice "when search is a secondary feature of a primarily-relational application at moderate scale." Concrete signals: search is one feature among several in an otherwise-relational application; the dataset doesn't genuinely require horizontal distribution; the team doesn't want to operate an entirely separate system alongside the primary database; and ts_rank()'s own simpler relevance model (search1-6) is genuinely sufficient for the actual use case — a "does this roughly match" search, not sophisticated relevance tuning.

When a Dedicated Search Engine Is Genuinely Worth It

• Search is the primary product, not a secondary feature — a job-search site, a documentation search product, an e-commerce search-and-discovery experience where search quality directly drives revenue.
• Genuinely large scale requiring real horizontal distribution (search1-8) that a single Postgres server or read-replica setup can't practically match.
• Faceted search/aggregations (search1-7) are a first-class, heavily-used product requirement, not an occasional nice-to-have.
• Sophisticated relevance tuning (search1-6's own BM25/boosting material) genuinely matters to the product's own success, not just "good enough" matching.
• Log/observability-style analytics workloads — a real, common, adjacent use case this course didn't go deep on, worth an honest namecheck.

The Real Operational Cost — Not Free

A direct callback to search1-1's own warn-box and search1-8's own distributed-architecture material: running a dedicated search engine means operating an entirely separate distributed system — real infrastructure, real operational expertise, and real ongoing complexity keeping two systems in sync. The primary database remains the source of truth, per search1-1's own warn-box, and the search index has to be kept up to date from that source of truth — real, ongoing engineering work, not a one-time setup cost. This has to be weighed honestly against the real benefits — "search is genuinely important to us" alone doesn't automatically justify this cost if postgres1-6's own built-in capability would actually suffice.

A Practical Decision Framework

1. Is search a primary product feature, or a secondary convenience? (Secondary → postgres1-6 is probably enough.)
2. Does the dataset/query volume genuinely require horizontal distribution beyond what a single well-resourced Postgres server can handle?
3. Is faceted search/real-time aggregation a genuine, heavily-used product requirement?
4. Does relevance quality itself materially affect the product's own success — not just "does the search work at all"?
5. Is the team prepared to operate and maintain an entirely separate distributed system, keeping it in sync with a real source of truth?

If most of these point toward a genuine "yes," a dedicated search engine is likely worth its real cost. If most point toward "no" or "not really," postgres1-6's own built-in full-text search is very likely the better, simpler choice.

The Honest Middle Ground

Not every real decision has a clean answer — some cases are genuinely ambiguous, and reasonable people disagree. This framework's own goal, matching sqlite1-7's own precedent, isn't a rigid flowchart that removes judgment — it's making sure that judgment is informed by the real trade-offs covered across this entire course.

Hands-On Exercises