Tachyon vs. PostgreSQL Full-Text Search
When Postgres's built-in tsvector/tsquery search is enough, and when a dedicated search engine like Tachyon earns its keep.
This isn't really Tachyon-vs-a-competing-search-engine — it's "do you need a
separate search engine at all." If your data already lives in Postgres and
your search needs are modest, tsvector/tsquery with a GIN index gets you
real full-text search with zero new infrastructure. Tachyon is worth the
second moving part once you outgrow what that built-in support does well.
At a glance
| Tachyon | Postgres full-text search | |
|---|---|---|
| Deployment | Separate service | Built into a database you likely already run |
| Typo tolerance | Built in, always on | Not built in — needs pg_trgm for approximate matching |
| Faceting | Built in, computed over the full result set | Not built in — hand-rolled with GROUP BY + COUNT |
| Relevance | BM25 | ts_rank/ts_rank_cd — term-frequency-based, no corpus-wide IDF term by default |
| Index type | Purpose-built inverted index | GIN index over tsvector columns |
| Data freshness | Indexed on write via the same API | Indexed on write via triggers or application code |
| Scaling search load | Independent of your primary database | Shares resources and I/O with your primary database |
| Operational cost | A second service to run and monitor | None beyond your existing Postgres |
Where Postgres full-text search is enough
If you're searching a few hundred thousand rows, don't need typo tolerance,
and your relevance requirements are "match the query terms, most-recent-
first is fine," Postgres's built-in search is genuinely enough — no new
service, no new failure mode, no data synchronization to keep correct.
tsvector/tsquery plus a GIN index is a well-understood, battle-tested
tool for exactly that job.
Where it starts to strain
Three things Postgres full-text search wasn't designed for, and where a dedicated engine earns the extra moving part:
- Typo tolerance. Nothing built in matches misspelled queries;
pg_trgmtrigram similarity is an approximation, not the same guarantee as edit-distance-based matching. Tachyon's typo tolerance is on by default and scales the allowed edit distance to query length — see Typo Tolerance. - Faceting.
GROUP BY+COUNTover a filtered result set works, but it's a query you write and optimize yourself for every facet, and it gets expensive as result sets grow. Tachyon computes facets over the whole matching set as a first-class query parameter — see Faceting. - Search load isolation. Full-text queries on your primary Postgres instance compete for the same I/O, connections, and cache as your transactional workload. A dedicated search engine — Tachyon or otherwise — takes that load off the database that's also serving your application's writes.
Migration shape
Moving from Postgres full-text search to Tachyon means denormalizing the searchable representation of each row into a flat JSON document — the same shape either way, whether the source is a single table or a join — and indexing it via Documents. Keeping the two in sync is the real cost: outbox pattern, logical replication into an indexer process, or a scheduled resync, depending on how fresh search results need to be.
Choose Postgres full-text search when
- You already run Postgres and your search needs are modest: no typo tolerance requirement, simple relevance is fine.
- You want zero new infrastructure.
Choose Tachyon when
- You need typo tolerance, real faceting, or BM25-quality relevance ranking.
- Search query load needs to be isolated from your primary database.
- You're prepared to run and keep in sync a second, purpose-built service.