Do I need to sync search from Postgres triggers?

Not necessarily. You only need Postgres triggers if your search index must stay in near-real-time and you don’t already have another reliable change-capture path.

Common approaches

1. Application writes + async indexing

   • Your app writes to Postgres.
   • It also publishes an event or job to update search.
   • Usually the preferred default.

2. CDC / logical replication / Debezium

   • Changes in Postgres are streamed to a queue or pipeline.
   • Search index updates happen from that stream.
   • Better than triggers for many production systems.

3. Postgres triggers

   • On insert/update/delete, a trigger emits a change record.
   • Can work, especially for smaller systems.
   • But triggers add coupling and can complicate transactions and performance.

When triggers make sense

• You need guaranteed capture of DB changes without changing app code much.
• You want the search update to be tightly coupled to the database transaction.
• The system is small/simple and operational overhead is low.

Downsides of triggers

• Extra write overhead on hot tables.
• Harder to maintain and test.
• Can create hidden behavior in the database.
• Still usually need an async worker to update the search engine anyway.
• If the search engine is down, you must not block DB writes—so you still need a queue/outbox/retry design.

Better pattern in many cases

Use an outbox table:

• Transaction writes business data + outbox event in the same Postgres transaction.
• A worker reads outbox rows and updates search.
• This gives strong consistency for “record the change” without putting search logic in triggers.

Rule of thumb

• No, you do not need triggers by default.
• Use triggers only if they’re the simplest reliable way for your system.
• For most production systems, app-level events or outbox/CDC are better.

If you want, I can recommend the best pattern based on your stack (e.g. Django, Rails, Node, Go, Elasticsearch/OpenSearch/Meilisearch).