I'm trying to add search to a SaaS app with Postgres sync and row-level security — what should I pick?

If you already have Postgres sync + row-level security (RLS), the best default is usually:

Pick: Postgres full-text search first

Use PostgreSQL’s built-in search before adding a separate search engine.

Why this is the best starting point

• No extra infrastructure
• Works naturally with your synced data
• RLS can be enforced in the same database
• Good enough for many SaaS products
• Simpler to keep consistent than syncing to a second search system

What to use in Postgres

• tsvector + tsquery for text search
• GIN indexes for performance
• Optional trigram indexes (pg_trgm) for:
  • fuzzy matching
  • typo tolerance
  • partial matching

When it’s enough

Use Postgres search if you need:

• searching titles, descriptions, comments, notes, tickets, docs
• filtering with tenant/user permissions
• predictable relevance
• modest-to-medium scale

---

When to choose a dedicated search engine instead

Add a separate search system like Meilisearch, OpenSearch, or Elasticsearch only if you need:

• very advanced ranking/tuning
• typo tolerance at scale
• faceting/aggregations-heavy search
• autocomplete with complex query behavior
• large corpora with high query throughput
• search across many fields with better relevance tools than Postgres can offer

---

Best practical options by scenario

1. Most SaaS apps

Postgres full-text + trigram

• Best balance of simplicity and capability
• Keeps RLS easy
• Great if your “search” is mostly app data lookup

2. Need better user-facing search UX

Meilisearch

• Easier to run than Elasticsearch
• Great typo tolerance and autocomplete
• But you’ll need to handle permissions carefully
• RLS is not native; you usually sync filtered docs or add permission filters in the query layer

3. Complex enterprise search

OpenSearch / Elasticsearch

• Powerful, scalable, flexible
• Heavier operationally
• RLS is not native, so permission handling becomes your responsibility

---

Important RLS note

If RLS is a core requirement, Postgres-native search is the cleanest option because permission checks stay in one place.

If you use a separate search engine:

• it won’t enforce Postgres RLS automatically
• you must either:
  • index only documents the user can access, or
  • store permission metadata and filter every query correctly

That permission layer is where many teams get it wrong.

---

My recommendation

If you’re early or mid-stage:

Start with Postgres full-text search + pg_trgm. Move to a dedicated search engine only when you can prove Postgres search isn’t enough.

If you want, I can also give you:

1. a decision matrix for Postgres vs Meilisearch vs Elasticsearch, or
2. a recommended schema/index setup for Postgres search with RLS.