starter.wiki

Data

Lexical & Product Search

Choose database-native or dedicated lexical search by corpus, relevance, latency, controls, synchronization, and operating constraints.

Recommendation

Start with PostgreSQL full-text search for a modest PostgreSQL-backed product.

Keeping search with the source data is the bounded default until corpus, relevance, latency, language, analytics, or product-control needs justify a second system.1

For: Applications whose searchable data already lives in PostgreSQL and whose lexical search requirements are still limited

Main trade-off

A dedicated engine adds specialized relevance and product controls while introducing a second data system, indexing lag, operations or vendor dependence, and another failure and cost surface.12345

Prove the need for a dedicated index

Search quality depends on the corpus and relevance contract, not merely response time or a vendor's feature count.

  1. Corpus and freshness

    Measure document and field count, update rate, indexing lag, deletion behavior, rebuild time, and source-of-truth synchronization.12

  2. Relevance and language

    Define analyzers, tokenization, typo tolerance, stemming, synonyms, boosts, facets, filters, and multilingual needs.12

  3. Product controls

    Identify analytics, merchandising, curation, personalization, experimentation, access control, and explainability requirements.12

  4. Operations and economics

    Model latency, availability, index size, replicas, requests, records, transfer, support, and migration ownership.4

When PostgreSQL search is no longer enough

Each exception adds a separate index and synchronization boundary in exchange for more specialized search capabilities.

Managed product-search controls matter

Evaluate Algolia.

Hosted operations, relevance configuration, analytics, and product-facing controls can shorten delivery for commerce and application search.

Verify: Request and record economics, vendor-specific indexing and ranking, data movement, and migration must be acceptable.12

You want a focused engine with operating choice

Evaluate Typesense.

Typo-tolerant search and self-hosted or managed deployment offer a focused alternative to a broad search platform.

Verify: Language, filtering, ranking, high availability, corpus scale, and operating responsibility must fit.13

A developer-focused engine fits the corpus

Evaluate Meilisearch.

Approachable APIs and hosted or self-hosted routes can serve moderate corpora with compatible relevance needs.

Verify: Verify language support, filtering, ranking, scale, high availability, licensing, and deployment edition boundaries.14

Advanced search and analytics are real requirements

Evaluate Elasticsearch.

Advanced analyzers, queries, aggregations, distributed indexing, and ecosystem integrations justify the broader platform for complex needs.

Verify: Index design, cluster or cloud operations, resource cost, and product or licensing choices are substantially larger.15

Boundary: Vector similarity belongs on Vector Search. The primary database remains the system of record; a dedicated search index is a derived read model with an explicit synchronization and recovery plan.

Official resources

Use the primary documentation to validate product boundaries, operating behavior, limits, and current commercial terms.

Sources

Official documentation supporting the decision routes and their boundaries.

  1. 1
    PostgreSQL full-text search

    PostgreSQL · Accessed Official

  2. 2
    Algolia documentation

    Algolia · Accessed Official

  3. 3
    Typesense Search API

    Typesense · Accessed Official

  4. 4
    Meilisearch documentation

    Meilisearch · Accessed Official

  5. 5
    Elasticsearch full-text search

    Elastic · Accessed Official