Elasticdump exists because people treat Elasticsearch as a place their data lives: it gets copied, backed up, migrated between clusters, and worried about. That raises a question that sounds pedantic right up until it costs someone their only copy of something — is Elasticsearch actually a database? Teams index their sole copy of important records into it, query it like a store, and build applications directly on top of it. If it holds the data and answers the queries, the label feels academic.
The honest answer is that Elasticsearch is a database-shaped search engine, and Elastic’s own documentation now says as much. Elastic defines it as “a distributed search and analytics engine, scalable document store, and vector database built on Apache Lucene,” storing data as JSON documents organised into indices. The “yes” case is therefore real, not a misunderstanding. But four hard limits decide the question in practice: no ACID transactions across documents, no real joins, near-real-time rather than immediate visibility, and updates that rewrite whole documents. This article lays out both sides, then the production pattern most teams land on — and the respectable counterpoint to it.
The short answer
Elasticsearch is a database in the loose sense that it durably stores data and serves it back on demand. It is not a database in the stricter sense that teams usually mean when they pick one as their system of record: it makes none of the cross-document guarantees a transactional database makes. Which sense matters depends on what you would lose if a write half-applied, a related record went missing, or a just-saved document did not show up in search for a second or two. Read the four limits below as a checklist against your own application, not as a verdict handed down from above. It also helps to separate two questions that get tangled together: “database” as a product category — a thing that stores and serves data — and “database” as a role, the one system whose word is final when copies disagree. Elasticsearch comfortably qualifies under the first meaning. The argument is entirely about the second.
The case for “yes, it is a database”
Start with what Elasticsearch plainly does, because the evidence is substantial:
- It stores data persistently. Structured and unstructured data alike is kept as JSON documents in indices, on disk, across a cluster — not cached, not derived on the fly, but stored.
- It supports full CRUD. Documents are created, read, updated, and deleted through REST APIs, alongside queries, filters, and aggregations that go far beyond simple key lookups.
- It is distributed and fault-tolerant. Indices are split into shards spread across nodes, with replicas keeping copies of the data so the loss of a node does not mean the loss of the store.
- People run it as a primary store. Plenty of production systems read and write Elasticsearch as their main data layer, which is exactly why the “is it a database” argument never dies — for those teams, functionally, it is one.
Elastic putting the words “document store” and “vector database” in its own definition matters too. The vendor is not shy about the database framing; the category is genuinely blurry. What keeps it from being a simple yes is not storage or querying — it is the guarantees, or rather their absence.
Limit 1: no ACID transactions across documents
This is the limit that decides the question for most applications. As the hosting provider Bonsai puts it: “Most databases are ACID compliant. Elasticsearch is not… Elasticsearch offers atomicity only on a per-document basis, not on a transaction basis.”
Concretely: a bulk request that updates ten documents can succeed for seven of them and fail for three, and Elasticsearch will not roll the seven back. A write that touches two indices — an order and its line items, an account and its balance — has no transaction wrapping it, so a failure halfway leaves the pair permanently inconsistent unless your application detects and repairs it. A traditional database treats that multi-record change as one atomic unit; Elasticsearch treats it as ten independent events. If your data has invariants that span documents — balances that must sum, seats that must not oversell — enforcing them becomes your code’s problem, with no safety net underneath.
Elasticsearch is not devoid of consistency tools: it offers per-document optimistic concurrency through sequence numbers, so a single document cannot be blindly overwritten by two writers at once. That is a real feature, but one document at a time is precisely the boundary. Its overall consistency model is eventual — replicas converge through replication and sharding rather than through transactional guarantees.
Limit 2: no joins
Elasticsearch is non-relational, and it does not support joins across indices the way SQL joins tables. Data that a relational schema would spread across linked tables must be modelled differently here, usually by denormalising — copying the needed fields into each document so every document stands alone.
Workarounds exist, and both come with warnings attached. Nested documents keep child objects attached to a parent inside one document; join fields create parent-child relationships between documents. Experienced practitioners caution that these mechanisms fail to operate efficiently at scale and should be used with care. In practice, the denormalised design is not a compromise but the intended style — it is part of why search is fast. The cost shows up when the same fact lives in fifty thousand documents and changes: there is no single row to update, only a mass edit to schedule and verify.
Limit 3: near-real-time, not immediate
In a traditional database, a committed write is visible to the next query. In Elasticsearch, a document becomes searchable only after a refresh of the index — so, as practitioners discussing this limitation put it, a recently acknowledged write may not show up until the next refresh. Comparisons of write visibility put Elasticsearch at roughly one second, near-real-time, against immediate visibility in a traditional database.
One second sounds trivial until a user saves a profile, the application immediately searches for it, finds nothing, and concludes the save failed — or a checkout flow reads back stock it just decremented and sees the old number. The standard fix is designing around it (fetch by ID, which is real-time, rather than searching; or request a refresh when you truly need one, sparingly). It is a manageable behaviour, but it is a behaviour no transactional database asks you to manage.
Limit 4: updates rewrite the whole document
Elasticsearch does not modify a document in place. An update marks the old version as deleted and writes an entirely new version of the document, consuming disk and setting up later segment merges to clean up the dead copies. A workload that churns — counters, statuses, frequently edited records — pays for this design continuously: more disk, more merge work, more deleted documents waiting for cleanup. For append-mostly data such as logs, events, and product catalogues, the cost barely registers. For OLTP-style workloads built on constant small mutations, it is a structural mismatch, not a tuning problem.
Side by side: Elasticsearch against a traditional database
| Question | Elasticsearch | Traditional database (relational or document) |
|---|---|---|
| Primary design goal | Full-text search and analytics over documents | Being the system of record |
| Multi-document transactions | No — atomicity is per-document only | Yes — ACID across records |
| Joins / relations | No joins; denormalise, or use nested/join fields cautiously | Native joins (relational) |
| Write visibility | Near-real-time, after a refresh (~1s) | Immediate on commit |
| Update mechanics | Whole document rewritten, old version marked deleted | In-place or versioned update |
| Schema enforcement | Mappings; wrongly typed data is rejected | Schema or document validation |
| Consistency model | Eventual, via replication | Transactional guarantees |
The standard production pattern
Put the limits together and a consensus architecture emerges, well described by practitioners who analyse Elasticsearch as a primary store: Elasticsearch is an OLAP system — built for analytical queries and aggregations — not an OLTP system built for transactional workloads. The common production pattern is therefore a pairing: an ACID database such as PostgreSQL holds the source of truth, and changes are replicated into Elasticsearch, which serves search and analytics. A change-data-capture pipeline between the two is a typical implementation. How the data gets moved in the first place is its own question — Elasticsearch does not extract from other systems itself, which is the subject of is Elasticsearch an ETL tool?
In this arrangement each system does the job its guarantees suit: the database owns correctness, Elasticsearch owns findability. When search results and the source of truth disagree for a moment, nobody loses money, because the truth lives somewhere with transactions.
A useful consequence follows from the pairing, and teams rely on it more than they say out loud: the index becomes rebuildable. If an Elasticsearch cluster in this pattern is lost or corrupted, the remedy is tedious but conceptually simple — reindex from the source of truth and carry on. Nobody describes losing their PostgreSQL database that way. That asymmetry is the sharpest practical test of the whole question: the system you can regenerate from the other one is not the database of record, whatever else it is, and the one you cannot regenerate is. Elasticsearch was designed for the regenerable side of that line.
The counterpoint: some teams run it as the store, successfully
Fairness requires the other side, because it exists and it is not foolish. Some operators run Elasticsearch as their system of record for years, at terabyte scale, and argue in practitioner discussions that the limits are manageable if you design around them from the start: model documents to be self-contained so transactions are rarely needed, read your own writes by ID instead of by search, keep update churn low, and be disciplined about backups. For search-centric data — the catalogue is the product, the log archive is the record — there may be no second system worth maintaining.
That position is legitimate, with one condition attached: it works for teams who chose it knowing the four limits, not for teams who discovered them in production. “Possible, with eyes open” is the accurate label — not the default recommendation, and not a mistake either. Designing around the limits tends to mean the same few disciplines, each aimed at one of the four: documents modelled to be self-contained, so cross-document transactions are rarely missed; reads of a just-written document done by ID rather than by search, so the refresh gap never surfaces; write patterns kept append-mostly, so whole-document rewrites stay cheap; and consistency checks run by the application itself, because nothing underneath will run them for you. None of that is exotic — but all of it is work a transactional database simply does on your behalf, and the honest comparison counts it.
Three misconceptions that muddy the question
“It is listed on DB-Engines, so it is a database like MongoDB.” DB-Engines and Wikipedia classify Elasticsearch first as what it is: the most popular enterprise search engine. The document-store behaviour is real but secondary — underneath everything sits a Lucene inverted index built for search, and the database-like features are layered on that foundation.
“NoSQL means no rules.” Elasticsearch has a schema: the mapping. Send a document whose field values clash with the mapped types and it is rejected, and changing a field’s type after the fact is not an edit — it means reindexing into a new index with the corrected mapping. Looser than a relational schema is not the same as absent.
“It stores my only copy, so at least backups are simple.” The logic runs the other way: the more database-like your use of Elasticsearch, the more backup discipline it demands. Cluster snapshots are the native route; portable, document-level copies are the other — the choice between them is laid out in Elasticdump vs snapshot and restore. And a store you depend on is one you must be able to empty and refill, which is why how to get all data from an Elasticsearch index is a production skill, not trivia.
FAQ
Can I use Elasticsearch as my only database?
You can, and some teams do, successfully, at serious scale. You give up multi-document transactions, joins, and immediate visibility to do it, so the decision should be made against those four limits explicitly — not discovered through them later.
Is Elasticsearch a NoSQL database?
In the broad taxonomy, yes: it is a distributed, non-relational store for JSON documents. The more useful description is Elastic’s own — a search and analytics engine that is also a document store — because “NoSQL database” invites comparisons its consistency model cannot cash.
Why does my document not appear in search results straight after I index it?
Because search sees documents only after an index refresh — roughly a second later by default. Fetching the document by its ID is real-time; searching is near-real-time. That gap is designed behaviour, not a bug.
Does Elasticsearch support transactions at all?
Only at the level of a single document, helped by optimistic concurrency via sequence numbers. There is no transaction spanning multiple documents or indices, and bulk operations can partially succeed with no rollback.
What should I use as the source of truth instead?
The common pattern is an ACID database — PostgreSQL is the usual example — holding the authoritative data, with changes replicated into Elasticsearch for search and analytics.
Does Elasticsearch have a schema?
Yes — the mapping, which declares each field’s type. If no mapping exists, Elasticsearch guesses types from the first documents it sees, which is how indices end up with a text field that should have been a date. Documents whose values clash with the declared types are rejected, and fixing a wrongly typed field means reindexing into a new index with a corrected mapping.
Conclusion
Elasticdump moves Elasticsearch data for a living precisely because so much data ends up living there — which makes the honest label worth getting right. Elasticsearch is a search and analytics engine with genuine document-store and even vector-database credentials, and it will hold your data durably and serve it back at remarkable speed. What it will not do is guarantee that multi-document changes apply atomically, join your records back together, show writes instantly, or update cheaply — and those four refusals, not its storage, are what separate it from a database in the system-of-record sense. Use it as the search layer over a transactional store, or use it as the store itself with the limits designed around. Just choose deliberately, and keep a copy of the data somewhere else either way.