La recherche dans votre produit en 2026 : Postgres, Meilisearch, Typesense, OpenSearch ou un hybride

La recherche est la fonction que les utilisateurs jugent en une demi-seconde et dans laquelle les ingénieurs sous-investissent pendant des années. Le paysage 2026 compte quatre familles crédibles : la recherche plein texte dans Postgres (le tsvector intégré, ou BM25 via pg_search 0.26 de ParadeDB), les moteurs légers conçus pour les résultats instantanés (Meilisearch 1.55, Typesense 30), le cluster poids lourd (OpenSearch 3.9, Elasticsearch), et les montages hybrides qui fusionnent résultats lexicaux et vectoriels. Cet article les compare sur les critères qui décident d'une recherche produit, montre ce que les recherches lexicale et sémantique manquent chacune, et donne une clé de décision et un score pondéré à rejouer avec vos propres poids.

Ce que chaque famille fait bien

Les scores sont notre lecture au 19 octobre 2026 (la colonne value est le poids que nous donnerions pour un SaaS B2B type ; changez-la pour le vôtre). Licences : Postgres et OpenSearch permissives, Meilisearch MIT, Typesense GPLv3, ParadeDB AGPLv3 avec une offre commerciale. Versions relevées sur les pages de publication : Meilisearch 1.55.0 (12 octobre), Typesense 30.2, OpenSearch 3.9.0, ParadeDB 0.26.2 (16 octobre).

Lexical et sémantique manquent des choses différentes

La recherche lexicale est précise sur le vocabulaire et aveugle au sens : elle trouve « frais de résiliation » et manque « ne plus être prélevé ». La recherche vectorielle est l'inverse : elle trouve l'intention et fait remonter « supprimer mon compte » quand l'utilisateur voulait garder son compte. Les deux se recouvrent sur la meilleure réponse, c'est pourquoi la recherche hybride, qui fusionne les deux listes classées (fusion de rangs réciproques, ou score pondéré), bat chacune seule sur la plupart des corpus produit, et pourquoi tous les moteurs du tableau la proposent désormais : Meilisearch avec un ratio sémantique, Typesense qui pondère le rang lexical à 70 % par défaut, OpenSearch avec normalisation des scores ou fusion de rangs, Postgres avec pgvector plus BM25 dans une seule requête SQL.

La latence est une distribution, pas un nombre

Les médianes flattent tout le monde ; la queue est ce que l'utilisateur ressent à la troisième frappe d'une recherche en temps réel. Les moteurs instantanés gardent le p99 sous 100 ms parce qu'ils tiennent l'index en mémoire (Typesense entièrement, Meilisearch en grande partie) et font la tolérance aux fautes à l'indexation. La queue de Postgres vient des revérifications de l'index GIN et du partage de la machine avec l'application ; pg_search la réduit. L'hybride coûte un appel d'embedding plus deux récupérations, ce qui convient à une page de résultats et reste trop lent pour la frappe en direct, sauf si la partie lexicale répond d'abord.

Lequel, en six questions

Une décision travaillée pour un SaaS B2B

Pour cette équipe, les deux premiers se tiennent à un point, ce qui est l'issue habituelle : Meilisearch pour la meilleure expérience de recherche avec un service de plus à exploiter, Postgres avec pg_search pour une pièce mobile de moins et aucun code de synchronisation. L'arbitrage est rarement technique : c'est de savoir si l'équipe veut posséder un pipeline d'indexation (capture des changements ou double écriture, réindexation aux changements de schéma, une alerte d'index périmé) ou préfère le payer en latence de requête.

Le compromis en une image

En résumé

Commencez dans Postgres : la recherche plein texte intégrée couvre plus de produits que les ingénieurs ne le pensent, et pg_search ajoute la pertinence BM25 et les facettes sans quitter la base. Passez à Meilisearch ou Typesense quand les utilisateurs tapent et attendent des réponses sous la frappe, et à OpenSearch quand le corpus ou l'analytique exigent un cluster. Quel que soit le moteur, rendez-le hybride : fusionnez résultats lexicaux et vectoriels, parce que les deux manquent des choses différentes. Nos articles sur la recherche vectorielle et le RAG et l'optimisation des bases de données couvrent la moitié sémantique et le réglage de Postgres.

Sources : pages de publication de Meilisearch, Typesense, OpenSearch et ParadeDB (lues le 19 octobre 2026) ; documentation des projets sur la recherche hybride ; notre banc d'essai pour les distributions de latence, qui illustrent une forme plutôt qu'un benchmark.