Adding a search engine introduces a second copy of your data that can drift from the first, an indexing pipeline that can fail silently, and an operational dependency someone has to run. Sometimes that is clearly worth it. Frequently the database you already have would do the job, and the migration was driven by the assumption that real search needs a search engine.
01What Postgres full-text search actually does well
Stemming, ranking, phrase queries, boolean operators, prefix matching and highlighting - all present, all reasonable, and all operating on data that is by definition current because it is the same rows. For a corpus in the hundreds of thousands with straightforward relevance needs, it is often entirely sufficient.
The decisive advantage is consistency. There is no index to fall behind, no reindex to run after a bad deploy, and no possibility of search results referencing a record that was deleted an hour ago. That class of bug simply does not exist.
| Requirement | Postgres | Dedicated engine |
|---|---|---|
| Basic keyword search | Good | Good |
| Typo tolerance | Weak | Strong |
| Faceted filtering at scale | Workable | Strong |
| Relevance tuning | Limited | Extensive |
| Multi-million document corpus | Struggles | Designed for it |
| Search-as-you-type | Possible, awkward | Native |
| Always current results | Guaranteed | Eventually |
02The synchronisation problem you are buying
A separate index means every write must propagate. That pipeline can fall behind, fail silently, or miss deletes - and a search result pointing at a deleted record is a bug users notice immediately and report as data loss.
Deletes are the specific weak point because they are easy to forget. An update path that reindexes on save but does nothing on destroy leaves ghosts in the index indefinitely, and nobody notices until a customer searches for something they deleted last month.
03Typo tolerance is usually the real driver
The requirement that most often genuinely justifies a search engine is fuzzy matching. Users misspell things constantly, and a search that returns nothing for a one-character error feels broken regardless of how good it is on exact matches.
Postgres can approximate this with trigram similarity, which works acceptably for short fields like names and product titles. Across long-form documents it becomes slow and imprecise, and that is the point where a dedicated engine starts paying for itself.
| Option | Operational burden | Best for |
|---|---|---|
| Postgres FTS | None, already running | Most applications under ~1M docs |
| Postgres plus trigram | None | Adding typo tolerance to short fields |
| Typesense / Meilisearch | Low | Typo tolerance, fast setup, mid-size corpora |
| Elasticsearch / OpenSearch | High | Large corpora, complex relevance, analytics |
| Hosted search API | Lowest | Small teams, willing to pay per operation |
04Relevance is a product problem
The default ranking of any engine is a starting point, not an answer. Real relevance comes from knowing which fields matter, how recency should weigh against textual match, and which results users actually click.
Instrument search from the beginning: query, result count, position clicked, and whether the session ended in success. Queries returning nothing are the highest-value list you can look at, because each one is a user who wanted something and left without it.
05A reasonable migration path
Start with the database. Instrument searches. When the data shows a specific failure - zero results for near-misses, unacceptable latency, filtering the engine cannot express - migrate with that evidence rather than on principle.
When you do migrate, keep the database search working as a fallback for the first few months. Index pipelines fail in their first weeks, and having a slower but correct path to fall back to is considerably better than a search box that returns nothing.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer