Exercise 3: When Built-In Full-Text Search Fits vs. When a Dedicated Search Engine Fits — Possible Solution ==================================================================== WHEN POSTGRES'S OWN FULL-TEXT SEARCH IS THE RIGHT CHOICE ------------------------------ Per this chapter, "Postgres's own full-text search is a real, built-in capability with no extra infrastructure to deploy — a genuine advantage for small-to-medium applications that need 'good enough' search without operating a whole separate system." And more specifically: "Postgres's own full-text search is the right choice when search is a secondary feature of a primarily-relational application at moderate scale." This means: if an application is fundamentally a relational system (an e-commerce site, a content management system, an internal tool) where search is one useful feature among many rather than the whole point of the product, and the scale is moderate rather than massive, Postgres's built-in capability is genuinely sufficient and avoids the real operational cost of running and maintaining an entirely separate search system. WHEN A DEDICATED SEARCH ENGINE IS THE RIGHT CHOICE ------------------------------ Per this chapter, "a dedicated search engine is the right choice when search itself IS the primary product, or when scale and sophistication genuinely demand it." Per the chapter's own list, dedicated engines like Elasticsearch/OpenSearch offer "distributed horizontal scaling across a cluster, more sophisticated relevance-tuning and language analyzers, faceted search/aggregations as a first-class feature, and typo-tolerant fuzzy matching out of the box — because search is their entire purpose, not a feature layered onto a general-purpose relational engine." This means: an application whose core product IS search (a job listings search site, a document discovery platform), or one that has genuinely outgrown a single-server relational database's own capacity, or one that needs sophisticated features Postgres doesn't attempt (typo tolerance, faceted filtering as a first-class capability) should reach for a dedicated engine instead. THE UNDERLYING PATTERN ------------------------------ Per this chapter, "this is the same 'when to choose each' judgment from postgres1-1, applied once more — this time between a built-in feature and an entirely separate system." The decision isn't about which is objectively better, but about matching the tool to the actual role search plays in the application and the actual scale/ sophistication genuinely required — the same non-absolutist framing this course has applied at the engine level (postgres1-1) and the type-design level (postgres1-3's own warn-box). WHY THIS WORKS AS AN ANSWER ------------------------------ It states both sides of the decision using the chapter's own precise wording and criteria (secondary feature/moderate scale vs. primary product/genuine scale-sophistication demand), and names the recurring decision-framing pattern the chapter itself calls back to.