SaaS Search at Scale: Postgres Full Text vs Algolia vs Typesense

What you need to know

• Postgres full-text search with GIN indexes handles search for most early-stage SaaS products. Add a dedicated search service when relevance, typo tolerance, or instant search are product requirements.
• Algolia provides the best developer experience and the highest-quality search out of the box, at the highest price.
• Typesense is the right alternative to Algolia for teams who want similar features with self-hosting capability and lower cost.
• Search indexing should be asynchronous and event-driven. Synchronous indexing adds write latency; scheduled full reindex produces stale results.
• Semantic search is different from keyword search and requires a separate vector infrastructure. Do not conflate the two.

The core argument

Search quality directly affects user experience in ways that are immediately visible. Users who search for something and get irrelevant results or no results conclude the product does not have what they need, even when it does. The search quality bar has risen as users experience Algolia-powered instant search everywhere and form expectations accordingly.

The decision for most SaaS products is: start with Postgres full-text for the simplest implementation, and migrate to Algolia or Typesense when search quality becomes a product concern. The migration is straightforward because search is an additive feature: the Postgres data remains the source of truth, and the search index is a derived read model. Migrating the search layer does not require changing the data model.

The signal for when to migrate is consistent: users searching and not finding what they clearly should find, or search feedback in user research that mentions slow or irrelevant results. Before that signal, Postgres full-text is the right balance of simplicity and functionality. After that signal, Algolia or Typesense provides the quality improvement without a data architecture change.

Common mistakes

1. Not using GIN indexes on tsvector columns. Postgres full-text search without GIN indexes produces sequential scans on every search query. Every table with a full-text search requirement needs a GIN index on its tsvector column (or a generated tsvector column). Without this index, full-text search performance degrades severely as the table grows.

1. Indexing everything in the search corpus. Search quality degrades when the index contains content the user is not searching for (system-generated content, metadata, deleted records). Curate what is indexed based on what users actually search for, and maintain the search index to remove records when the corresponding data is deleted or archived.

1. Building synchronous indexing for Algolia or Typesense. Calling the Algolia or Typesense API synchronously in the same request as the database write adds the search API latency to every write operation. Build search indexing as an asynchronous background operation triggered by database change events.

1. Not implementing search analytics. Tracking what users search for and whether they click on results provides invaluable data for search quality improvement. Search queries with zero results are product feedback (users are looking for things the product does not have or cannot find). Implement search analytics before optimizing search relevance, because the analytics data directs optimization effort.

1. Using the same search configuration for all content types. A product where users can search both documents and people needs different relevance configuration for each content type (searching for a person's name should match the name field at highest priority; searching for document content should match the body at highest priority). Use separate search indexes or separate configurations per content type.

Where to start

1. Implement Postgres full-text with GIN index for the primary search surface. Add a generated tsvector column to the primary searchable table, create a GIN index on it, and write queries using the @@ operator with to_tsquery. Test the search with representative queries from users and verify that the results are relevant.

1. Instrument search with query logging and result click tracking. Log every search query, the number of results returned, and whether the user clicked a result. This data identifies zero-result queries (immediate improvement opportunities) and low-click-through queries (relevance issues). Review this data weekly before investing in search infrastructure changes.

1. Evaluate Algolia or Typesense if the search instrumentation reveals relevance or latency problems. The evaluation criteria: does the search service produce better results for the queries users are actually running? Test with the real query data from the search logs. If the improvement is significant for the user-facing use case, the migration cost is justified.

Related reading

• Query Optimization in PostgreSQL: Real Examples From Real Projects
• RAG (Retrieval Augmented Generation) for SaaS: When It Helps and When It Does Not
• PostgreSQL Performance at Scale: The Tweaks That Move the Needle
• SaaS Analytics Infrastructure: PostHog vs Mixpanel vs Snowflake vs Build Your Own