When to use Elasticsearch

Elasticsearch shines when users need flexible find and fast analytics over large document sets. It struggles when you treat it as a transactional system of record.

Good fits

• full-text search with ranking (products, profiles, knowledge bases, logs)
• faceted navigation and dashboard-style aggregations
• high-read, append-heavy or near-real-time document feeds
• secondary indexes that can be rebuilt from a primary store

In platforms with search APIs (mobile backends, academic profiles, log analytics), Elasticsearch is often the read model — not the ledger.

Poor fits

• the only copy of money, inventory, or identity state
• strong multi-document transactions and complex relational joins as the core model
• workloads that need strict serializability on every write
• “just put Postgres rows in ES and mutate them forever” without a rebuild story

If losing the cluster would lose irreplaceable business truth, the design is wrong. Keep the source of truth in a database (or event log) and treat Elasticsearch as a derived index.

Dual-write caution

Writing to DB and ES in two commits without an outbox/CDC path guarantees drift. Prefer:

1. commit to the system of record
2. publish a change (outbox / CDC / stream)
3. index asynchronously, with replay to repair

Smell test

Ask: Can we delete this index and rebuild it from something authoritative? If no, stop — you have accidentally made Elasticsearch the database.