---
title: "Postgres Full Text Search vs the rest"
description: "The post compares PostgreSQL Full Text Search with dedicated search engines including MeiliSearch, OpenSearch, SQLite FTS, and Typesense, asking whether a separate system is justified for common application search. It presents a PostgreSQL setup using a generated stored column built with to_tsvector('english', ...) and a GIN index, queried with websearch_to_tsquery. The benchmark loads a movie dataset and focuses on query speed after data ingestion, using comparable scripts and default configurations with limited tuning. PostgreSQL was close in performance to several alternatives; in-memory SQLite was fastest, while Typesense and MeiliSearch handled misspellings correctly and OpenSearch ingested data quickly. The conclusion is that PostgreSQL can provide good-enough search quality and speed for basic cases without adding another system, although dedicated engines offer capabilities PostgreSQL does not."
---

# Postgres Full Text Search vs the rest

[Supabase](https://yomu.fyi/company/supabase) · victor · Oct 14, 2022

**Type:** Benchmark

## Summary

The post compares PostgreSQL Full Text Search with dedicated search engines including MeiliSearch, OpenSearch, SQLite FTS, and Typesense, asking whether a separate system is justified for common application search. It presents a PostgreSQL setup using a generated stored column built with to\_tsvector('english', ...) and a GIN index, queried with websearch\_to\_tsquery. The benchmark loads a movie dataset and focuses on query speed after data ingestion, using comparable scripts and default configurations with limited tuning. PostgreSQL was close in performance to several alternatives; in-memory SQLite was fastest, while Typesense and MeiliSearch handled misspellings correctly and OpenSearch ingested data quickly. The conclusion is that PostgreSQL can provide good-enough search quality and speed for basic cases without adding another system, although dedicated engines offer capabilities PostgreSQL does not.

## Context

The comparison asks whether applications that already use PostgreSQL should add a dedicated search engine such as MeiliSearch, OpenSearch, SQLite FTS, or Typesense. It focuses on the trade-off between PostgreSQL's simpler integration and the search capabilities and performance of specialized systems, using minimal setup and tuning.

## Approach / What changed

The post reviews PostgreSQL's basic LIKE matching and built-in Full Text Search, then configures a generated stored tsvector column over movie title and overview fields with a GIN index. It converts a movie dataset to newline-delimited JSON, loads comparable documents into each system, and measures end-user query speed after ingestion, largely using default configurations. It also compares result behavior, including misspelling handling.

## Takeaways

- PostgreSQL Full Text Search can combine fields into a generated tsvector column and use a GIN index for faster searches; queries can be issued with websearch\_to\_tsquery.
- In the reported small movie dataset, in-memory SQLite was fastest and PostgreSQL was not far behind, while PostgreSQL was generally close in performance to several other systems in their default configurations.
- Typesense and MeiliSearch handled the misspelled “suprman” query, whereas OpenSearch’s default configuration did not index misspellings; Typesense’s match strictness is configurable.

**Tags:** [Performance](https://yomu.fyi/topic/performance), [Postgres](https://yomu.fyi/topic/postgres), [Search](https://yomu.fyi/topic/search)

- Source: [Supabase](https://supabase.com/blog/postgres-full-text-search-vs-the-rest)
- Source URL: https://supabase.com/blog/postgres-full-text-search-vs-the-rest
- Ingested by Yomu: 2026-08-29T01:14:22.971Z

[Read original post](https://supabase.com/blog/postgres-full-text-search-vs-the-rest)