When is Elasticsearch a poor fit as the primary database?

Question

IT Interview Practice · Accepted Answer

Elasticsearch can store data durably. To decide whether it should be the primary database, ask **which business rules must remain true when writes fail or run concurrently**.

For an order system, finding products and confirming a purchase are different jobs. Search relevance matters for the first; correct payment and inventory changes matter for the second.

## 1. Start with the changes that must succeed together

Suppose a purchase needs an order record and a stock reduction. The business must define what should happen if only one succeeds.

```text
[Create order] ---- must coordinate ---- [Reduce stock]
      |                                      |
   success                                failure?
```

Elasticsearch's bulk API submits several document operations together, but one item can fail while another succeeds. It does not make those operations an all-or-nothing transaction. The application must inspect individual results. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

If the requirement is an atomic change across records, a transactional database usually provides a more direct foundation. Implementing that coordination yourself adds failure cases and recovery work.

## 2. Distinguish document protection from business guarantees

Optimistic concurrency control checks that a document has not changed since the version you read. It can reject an outdated update, preventing one client from silently overwriting another client's work. [Concurrency control](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

That protection applies to the document being updated. It does not automatically coordinate the stock document with the order document, provide relational foreign keys or enforce arbitrary uniqueness rules across business fields.

Write down the rules the application needs before choosing storage. This makes the decision concrete instead of relying on the label “search engine” or “database”.

## 3. Check when a write becomes searchable

A successful write and a visible search result are separate events:

```text
[Write accepted] -> [Refresh] -> [Search can see the change]
```

A refresh makes recent changes visible to search. A real-time lookup by document ID therefore differs from a search query. The refresh=wait_for option can wait for search visibility, but does not create a multi-document transaction. [Refresh behavior](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

For a product search page, a short visibility delay may be acceptable. For a final payment or permission decision, define the required consistency explicitly and read a source that provides it. Refresh and durable storage are also different concerns.

## 4. Choose the role Elasticsearch should play

| Requirement | Direction to evaluate | Reason |
| --- | --- | --- |
| Orders and related records must change atomically | Transactional primary database | The required correctness rules belong near the authoritative records. |
| Users need flexible full-text search | Elasticsearch as a search copy | Search data can be shaped and rebuilt independently. |
| Independent documents with compatible consistency needs | Elasticsearch as the main store may fit | A second database should have a demonstrated purpose. |

A common order-system design is:

```text
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
 authoritative data                               search copy
```

CDC captures committed changes; an outbox records an event alongside the business update in the same transaction. A separate process delivers those changes to the index. This avoids relying on two unrelated application writes always succeeding together.

The indexing path still needs stable IDs, version handling, deletes, retries and lag monitoring. Test rebuilding the index from the source. Otherwise, a search copy can become a second, inconsistent source of truth.

## 5. Confirm the recovery model before committing

Whatever role is chosen, plan backups and test restoration. Replicas help availability but are not a substitute for backups. Define acceptable data loss and recovery time for the actual configuration.

For the order example, I would keep transactional records in a database that supports their rules and add Elasticsearch if search requirements justify it. For independent search-oriented documents, I would assess whether Elasticsearch alone meets storage, consistency and recovery needs.

**Remember:** choose by the guarantees the workload needs, then verify failure and recovery behavior. Search speed is only one part of that decision.

Requirement	Direction to evaluate	Reason
Orders and related records must change atomically	Transactional primary database	The required correctness rules belong near the authoritative records.
Users need flexible full-text search	Elasticsearch as a search copy	Search data can be shaped and rebuilt independently.
Independent documents with compatible consistency needs	Elasticsearch as the main store may fit	A second database should have a demonstrated purpose.

1. Start with the changes that must succeed together

2. Distinguish document protection from business guarantees

3. Check when a write becomes searchable

4. Choose the role Elasticsearch should play

5. Confirm the recovery model before committing

Related questions