Skip to main content
PostgreSQL includes built-in full-text search capabilities through its tsvector and tsquery data types, and the pgvector extension adds vector similarity search. While convenient for simple use cases, PostgreSQL’s search falls short compared to dedicated search engines for user-facing applications. This page compares Meilisearch with both approaches: PostgreSQL full-text search first, then vector and hybrid search with pgvector.

​
Quick comparison

​
What PostgreSQL FTS does well

​
Single-system simplicity

Keeping search in your existing PostgreSQL database means no additional infrastructure to manage. For simple use cases, this reduces operational complexity.

​
Transactional consistency

Search results are always consistent with your primary data, with no synchronization lag between database and search index.

​
SQL integration

You can combine full-text search with regular SQL queries, joins, and aggregations in a single statement.

​
When to choose Meilisearch instead

​
You need typo tolerance

PostgreSQL’s default full-text search cannot handle misspellings. The pg_trgm extension helps but doesn’t provide true fuzzy matching with word proximity awareness. Meilisearch handles typos automatically with configurable tolerance per attribute. Implementing faceted search in PostgreSQL is complex and resource-intensive, especially with multiple facet types and counts. Meilisearch provides optimized, first-class APIs for facet filtering and counting.

​
You need instant search-as-you-type

PostgreSQL isn’t optimized for the sub-50ms response times needed for search-as-you-type experiences. Full-text search queries on large datasets become costly, especially when ranking results.

​
Your users speak non-Latin languages

PostgreSQL lacks dictionaries for Chinese, Japanese, Korean, and other languages requiring complex tokenization. Meilisearch provides optimized support for these languages with automatic detection.

​
You want frontend integration

Search engines like Meilisearch work with InstantSearch libraries, providing pre-built UI components for search bars, facet filters, pagination, and more. PostgreSQL has no equivalent ecosystem.

​
You need a public-facing search API

Meilisearch provides a secure REST API designed for public consumption with API key management and tenant tokens for multi-tenancy. Exposing PostgreSQL directly to clients creates security risks and requires building a custom API layer.

​
Scaling is a concern

Full-text search queries on large PostgreSQL datasets compete for resources with your primary application workload. A dedicated search engine scales independently and uses data structures optimized for search operations.

​
You want better relevancy

PostgreSQL’s ts_rank only supports attribute weighting. Meilisearch offers configurable ranking rules for typo count, word proximity, exact matches, and custom business logic.

​
Vector and hybrid search: pgvector

The pgvector extension adds a vector data type, distance operators, and optional approximate nearest neighbor (ANN) indexes to PostgreSQL. It is a storage and query layer, not a search engine: everything that turns raw vectors into a search experience (embedding generation, hybrid fusion, relevancy scoring, filtered vector search) is left for your application to build. Meilisearch ships all of it out of the box.

​
Embedding pipeline: built-in vs do-it-yourself

pgvector stores and queries vectors, but it never calls an embedding provider. Generating vectors is entirely your application’s responsibility: calling the model API, batching, retries, API key management, and dimension mapping all happen in your code before insertion, and again at query time to embed the user’s search terms. This is a permanent piece of infrastructure you have to build, monitor, and maintain. With Meilisearch, you configure an embedder declaratively: OpenAI, Cohere, Mistral, Voyage, Jina, Hugging Face, Amazon Bedrock, Gemini, or any REST API. Meilisearch calls the model automatically at indexing time and at query time. There is no embedding pipeline to build, and switching models is a settings change, not a code rewrite.

​
Hybrid search: one query vs two

With pgvector, hybrid search is not a single query. You run a full-text query and an ANN query separately, then merge the two result lists yourself, either in application code or with SQL CTEs, typically using Reciprocal Rank Fusion (RRF) or a cross-encoder. That fusion logic is search-engine internals you now own, test, and tune. In Meilisearch, hybrid search is a single query with a hybrid: { semanticRatio, embedder } parameter. The fusion of keyword and semantic results happens inside the engine, and one slider controls the balance between the two.

​
Score fusion: RRF vs relevancy scores

pgvector’s documentation recommends RRF to merge full-text and vector results. RRF combines documents based on their rank in each list, not their actual relevance. It assumes the top semantic result is as relevant as the top full-text result, which breaks down whenever one of the two methods performs poorly on a given query. Meilisearch computes an absolute relevancy score between 0 and 1 for every document, comparable across both search methods. It also applies a correction for the typical compression of embedding similarity scores, which often cluster between 0.5 and 0.7 even for unrelated content. A weak semantic match cannot outrank a strong keyword match purely by position: documents win on actual relevance, not on rank arithmetic. pgvector performs exact nearest neighbor search (brute-force KNN) by default. Recall is perfect, but every query scans every vector, so latency grows linearly with your dataset. To make vector search fast at scale, you opt into an ANN index and take on its decisions yourself: HNSW or IVFFlat, index build parameters, and per-query tuning like ef_search. Meilisearch made that choice for you. Vector search runs on Hannoy, a purpose-built HNSW-based, disk-backed vector store tuned for fast user-facing search at scale, with no index type to pick and no per-query knobs to tune. If your use case genuinely requires 100% recall on every query, pgvector’s exact mode covers it; for search experiences, where consistent sub-50ms responses matter more than the last percentile of recall, ANN is the standard and Meilisearch delivers it without the tuning burden. With a pgvector ANN index, WHERE clauses apply after the index scan. This is one of the most common production surprises with pgvector: a selective filter silently degrades results. Filtering down to 10% of rows with the default ef_search of 40 returns only about 4 results on average, and fixing it means enabling iterative scanning or tuning index parameters query by query. Meilisearch filtering is native to the engine and integrated with vector search. Hannoy adapts its search strategy based on how many documents match the filter relative to the total, switching to linear scanning when the candidate set is small. Selective filters return full result sets with no hidden recall loss and nothing to tune.

​
Quantization and dimension limits

pgvector offers several storage formats: halfvec (16-bit floats), binary vectors, and sparse vectors. Each is a schema-level decision you make per column, and changing your mind means migrating the column and rebuilding indexes. Meilisearch offers binary quantization as a single index setting. It is particularly effective for high-dimensional models (above roughly 1,500 to 3,000 dimensions), where the impact on recall is minimal compared to the gains in disk usage and indexing speed. Dimension limits follow the same pattern. pgvector documents hard ceilings: 2,000 dimensions for full-precision vector, 4,000 for halfvec, and 64,000 for binary vectors. Modern high-dimensional embedding models can bump into the full-precision ceiling, forcing you into a different column type. Meilisearch documents no dimension limit, and vectors above 3,000 dimensions run in production today, with binary quantization as the standard recommendation as dimensions grow.

​
Incremental index updates

pgvector’s own documentation notes that VACUUM on an HNSW index can be slow and recommends reindexing before vacuuming. On a catalog that changes frequently, that is a recurring maintenance cost to schedule and monitor. Hannoy was designed specifically to keep incremental updates cheap: it merges new vectors into the existing graph and re-indexes less than 1% of existing vectors on a typical insertion. Frequently updated datasets are a first-class scenario for Meilisearch, not a maintenance chore.

​
When pgvector might be enough

Consider pgvector if:
  • You need exact nearest neighbor search with guaranteed recall on every query
  • You have already built and maintain an embedding pipeline, and vector search is an internal feature rather than a user-facing experience
  • You want vectors to live next to your relational data with transactional guarantees, and search quality is not the priority

​
When PostgreSQL FTS might be enough

Consider PostgreSQL full-text search if:
  • You have a small dataset (thousands of documents)
  • Search isn’t user-facing or real-time search isn’t required
  • Basic keyword matching is sufficient
  • You can’t add additional infrastructure
  • You’re using a managed PostgreSQL service that restricts extensions

​
Migration resources

Ready to upgrade from PostgreSQL full-text search:
PostgreSQL is a registered trademark of the PostgreSQL Global Development Group. This comparison is based on publicly available information and our own analysis.