Adding full-text search to Postgres is a two-line migration. Running it in production without surprises is not. The GIN index that makes search fast also adds write amplification and a background cleanup process that can quietly fall behind under a heavy insert rate, and "relevance" that looked fine on your laptop can drift the day someone changes a dictionary. Before you decide Postgres search is or isn't enough, you need evidence — a load test against your real write rate and a relevance contract you can measure — not just a row count.
I wrote earlier about why Postgres full-text search is usually the right first stop instead of standing up Elasticsearch. A reader pushed back with a sharp point: "one fewer service" doesn't mean zero search-specific operations. That's correct, and it's the part most tutorials skip. This post is the operations half of the story.
Why does the GIN index slow down my writes?
A GIN (Generalized Inverted Index) maps each lexeme to the list of rows that contain it. When you insert or update a row, every lexeme in its tsvector has to be threaded into the index — a document with 200 distinct word roots touches 200 posting lists. That is the write amplification the reader flagged: one row write becomes many index writes.
