Search infrastructure is the layer that lets users find things in your product by typing partial words, fuzzy terms, or natural language.
Search infrastructure is the layer that turns a user's typed query into a ranked list of matching results. Naive implementations use SQL LIKE queries and work for a few hundred rows before latency and relevance collapse. Real search requires a purpose-built index — Postgres full-text search, Elasticsearch or OpenSearch, Algolia, Typesense, MeiliSearch — with support for tokenization, stemming, fuzzy matching, and ranking. The choice depends on scale, latency requirements, and how much of the search team you want to hire.
If your data is already in Postgres, its built-in full-text search (tsvector, tsquery, GIN indexes) is genuinely capable — handles stemming, weighted fields, ranking, and phrase queries; scales to millions of rows on modest hardware. Advantages: no additional infrastructure, transactionally consistent with your source data, no sync layer to break. Limitations: relevance tuning is manual, typo tolerance requires the pg_trgm extension, faceted search is awkward. Rule of thumb: Postgres FTS handles most SaaS search needs up to about 10M documents and 100 QPS. Below that scale, switching to dedicated search infrastructure often costs more than it delivers.
Signals that Postgres FTS has run out: query latency exceeds targets (>200ms p95), relevance requires custom scoring you can't express in Postgres, you need real-time faceting across many dimensions, or you have distinct content types with different scoring needs. Elasticsearch/OpenSearch is the incumbent open-source choice — extremely powerful, extremely operationally heavy. Running it well requires dedicated attention; running it badly produces mysterious cluster incidents. Consider managed offerings (Elastic Cloud, AWS OpenSearch, Bonsai) unless you have a search engineer.
Algolia is the premium hosted search: excellent developer experience, sub-50ms latency globally via edge, sophisticated ranking, expensive at scale (per-record + per-search pricing). Best for consumer-facing search where UX quality drives revenue. Typesense and MeiliSearch are open-source alternatives inspired by Algolia's DX, self-hostable or hosted, cheaper at scale but with smaller ecosystems. Vector search (for semantic/embedding-based search) is increasingly first-class in all of them — Pinecone, Weaviate, Qdrant are vector-native options if that's the primary workload.
Whatever engine you pick, you need to keep the index in sync with your source of truth. Patterns: (1) synchronous — write to both DB and index in the same request. Simple, but doubles write latency and creates consistency problems if either fails. (2) async via CDC or outbox — writes go to DB, a change stream feeds the index. More complex, more robust. (3) periodic reindex — rebuild the index from scratch on a schedule. Fine for small datasets, impractical at scale. Most production systems use pattern 2; getting it right is where a lot of the operational work lives.
The search engine is 20% of the work; relevance tuning is 80%. Real search improvement requires: click-through rate tracking (which results do users actually pick), synonym dictionaries (jeans = pants for e-commerce), boost rules (recent content, popular items), typo tolerance calibration, and A/B testing infrastructure for relevance experiments. Teams that install a search engine and never tune relevance get most of the operational cost and half the user value; treating relevance as an ongoing product surface, not a one-time setup, is what separates good search from mediocre search.
Investor directory · Fundraising library · Articles A–Z · Company funding database