# Can You Use Elasticsearch as a Database? Architecture vs Relational Databases

> Explore using Elasticsearch as a database. Discover its search engine architecture versus relational databases for performance and functionality.

- Repository: [elastic/elasticsearch](https://github.com/elastic/elasticsearch)
- Tags: architecture
- Published: 2026-02-19

---

**Elasticsearch is architected as a distributed, near-real-time search engine rather than an ACID-compliant relational database, making it unsuitable for transactional workloads despite exceptional performance for full-text search and analytics.**

When evaluating **Elasticsearch as a database** for modern applications, developers must understand its fundamental architectural divergence from traditional relational database management systems (RDBMS). As implemented in the `elastic/elasticsearch` repository, this distributed search engine optimizes for inverted indexing and horizontal scalability rather than atomic transactions and referential integrity.

## Core Architectural Differences

### Data Model and Schema Flexibility

Relational databases enforce **fixed schemas** with strongly typed tables, foreign keys, and cascading constraints. Elasticsearch stores data as **schema-less JSON documents** with optional mappings that define field types. While this flexibility accelerates development for heterogeneous data, it eliminates native support for referential integrity and cascading deletes.

### Storage Engine Implementation

In [`server/src/main/java/org/elasticsearch/index/IndexService.java`](https://github.com/elastic/elasticsearch/blob/main/server/src/main/java/org/elasticsearch/index/IndexService.java), Elasticsearch implements an **inverted index per shard** structure optimized for search relevance scoring. This contrasts sharply with relational databases that utilize row-oriented storage with B-tree indexes. Writes append to a transaction log and refresh periodically (default 1 second) rather than offering immediate durability.

### Distributed Consistency Model

According to [`server/src/main/java/org/elasticsearch/search/SearchService.java`](https://github.com/elastic/elasticsearch/blob/main/server/src/main/java/org/elasticsearch/search/SearchService.java), Elasticsearch provides automatic **sharding** (default 5 primary shards) and **replication** (default 1 replica) across nodes. All nodes can function as data, master, or coordinating nodes. However, Elasticsearch guarantees **near-real-time consistency**—documents become searchable only after the refresh interval—rather than the strong read-your-writes consistency of ACID systems.

## Query Language and Relationship Handling

### Native Query DSL vs SQL

Elasticsearch primarily uses a **JSON-based Query DSL** for constructing searches. While the SQL plugin (documented in [`x-pack/plugin/sql/README.md`](https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/sql/README.md)) enables limited SQL compatibility, it translates queries to the underlying DSL and cannot support complex sub-queries, window functions, or full relational semantics.

### Limited Join Capabilities

Unlike relational databases with native multi-table joins, Elasticsearch restricts relationships to **parent-child**, **nested**, and **join field** constructs. The documentation in [`docs/reference/elasticsearch/mapping-reference/parent-join.md`](https://github.com/elastic/elasticsearch/blob/main/docs/reference/elasticsearch/mapping-reference/parent-join.md) explicitly warns that "multiple levels of relations add overhead," recommending denormalization instead. Each document write is atomic, but cross-document consistency must be handled at the application level.

## When Elasticsearch Excels as a Storage Solution

**Elasticsearch as a database** delivers superior performance for specific workloads:

- **Full-text search** – The inverted index enables phrase matching, relevance scoring, and fuzzy queries in milliseconds compared to table scans in RDBMS.
- **Scalable analytics** – Aggregations run in parallel across shards, processing terabytes of semi-structured data with horizontal scaling.
- **Schema evolution** – Ingest heterogeneous JSON without migration scripts or schema alterations.

## Critical Limitations for Transactional Workloads

Do not use Elasticsearch for general-purpose storage when requirements include:

- **Multi-document ACID transactions** – Banking, inventory management, and financial systems requiring atomic multi-row updates.
- **Complex relational queries** – Multi-table joins, correlated sub-queries, and constraint enforcement.
- **Strong consistency requirements** – The near-real-time refresh model (default 1 second) means recently written documents are not immediately visible.
- **Referential integrity** – Foreign-key enforcement and unique constraints must be implemented in application code.

## Practical Implementation: Java Client Example

The following example uses the **Java High-Level REST Client** (implemented in [`client/rest/src/main/java/org/elasticsearch/client/RestClient.java`](https://github.com/elastic/elasticsearch/blob/main/client/rest/src/main/java/org/elasticsearch/client/RestClient.java)) to demonstrate the write and read paths handled by [`IndexService.java`](https://github.com/elastic/elasticsearch/blob/main/IndexService.java) and [`SearchService.java`](https://github.com/elastic/elasticsearch/blob/main/SearchService.java):

```java
// Indexing a document (writes to transaction log, refreshes periodically)
IndexRequest request = new IndexRequest("products")
    .id("1")
    .source(Map.of(
        "name", "Wireless Mouse",
        "category", "electronics",
        "price", 29.99,
        "description", "Ergonomic wireless mouse with USB receiver"
    ));
client.index(request, RequestOptions.DEFAULT);

// Distributed search across shards
SearchRequest sr = new SearchRequest("products");
sr.source(new SearchSourceBuilder()
    .query(QueryBuilders.matchQuery("description", "wireless"))
    .size(5));
SearchResponse resp = client.search(sr, RequestOptions.DEFAULT);
resp.getHits().forEach(hit -> System.out.println(hit.getId() + ": " + hit.getSourceAsString()));

```

## Summary

- **Elasticsearch** optimizes for distributed search and analytics through inverted indexing, not transactional storage.
- **Near-real-time consistency** (1-second refresh default) makes it unsuitable for systems requiring immediate read-after-write guarantees.
- **Parent-child joins** exist but impose performance penalties; denormalization is the recommended data modeling approach.
- **No multi-document transactions** exist; atomicity is limited to single-document operations.
- The typical pattern uses **Elasticsearch as a secondary index** in front of an RDBMS, syncing data for search while keeping transactional authority in the relational database.

## Frequently Asked Questions

### Can Elasticsearch completely replace PostgreSQL or MySQL?

No, Elasticsearch cannot replace traditional relational databases for general-purpose storage. While it excels at search and analytics, it lacks ACID transactions, foreign-key constraints, and complex join capabilities essential for transactional applications. The recommended architecture maintains authoritative data in an RDBMS and streams relevant documents into Elasticsearch for fast querying.

### Does Elasticsearch support standard SQL queries?

Elasticsearch provides an SQL plugin that offers limited SQL compatibility through translation to the native Query DSL. However, as documented in [`x-pack/plugin/sql/README.md`](https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/sql/README.md), this implementation does not support full relational semantics, complex joins, or transactional SQL operations. It is suitable for simple reporting but not for replacing SQL-based application logic.

### How does data consistency work in Elasticsearch?

Elasticsearch provides **eventual consistency** with a near-real-time refresh model. When you index a document, it writes to a transaction log on the primary shard, but the document remains unsearchable until the next refresh interval (default 1 second). Primary-replica replication ensures durability, but replicas may lag slightly behind the primary, creating brief windows of inconsistency.

### What is the best way to model relationships in Elasticsearch?

The most performant approach is **denormalization**—embedding related data within documents rather than using joins. If you must model relationships, use **parent-child** or **nested** fields only for shallow hierarchies, as implemented in the mapping reference at [`docs/reference/elasticsearch/mapping-reference/parent-join.md`](https://github.com/elastic/elasticsearch/blob/main/docs/reference/elasticsearch/mapping-reference/parent-join.md). Avoid multiple levels of parent-child relations, which add significant query overhead and memory pressure.