What Is a match_all Query in Elasticsearch?
A beginner-friendly, deep walkthrough of the simplest query Elasticsearch offers — one that asks for absolutely everything, and why that simplicity is more useful than it first appears.
Imagine walking into a giant library and, instead of asking a specific question, simply saying: “show me every single book you have.” No filtering, no searching for a particular word, no ranking by relevance — just everything, exactly as it is. In Elasticsearch, this exact request has a name: the match_all query, and despite its almost comical simplicity, it plays a surprisingly important role in how people explore, test, and build on top of real data.
1What Exactly Is a match_all Query?
Before anything else, let’s build a clear, simple definition.
A match_all query is the simplest possible query in Elasticsearch’s query language: it matches every single document in the target index, without applying any filtering criteria whatsoever. It doesn’t look at any field, doesn’t check for any word, and doesn’t exclude anything — it simply says “everything counts.”
Every document matched by a match_all query receives the exact same relevance score, by default a flat value of 1.0. This makes intuitive sense: relevance scoring exists to answer the question “how well does this document match what was asked for,” and since nothing specific was asked for, there’s no meaningful way to say one document matches “better” than another.
Think of a teacher taking daily attendance by simply reading out the entire class roster, one name at a time, without checking anyone’s grades or behavior first. Everyone on the list gets called, in the same neutral way — nobody is ranked as “more present” than anyone else. That flat, no-judgment inclusion of everyone is exactly what match_all does with documents.
match_all
A query clause that matches every document in the index, with no filtering conditions applied.
Relevance Score
A number indicating how well a document matches a query; match_all assigns the same score to all.
Query DSL
Elasticsearch’s structured query language, of which match_all is the most basic possible clause.
Pagination
The mechanism used to retrieve large result sets, like a full match_all result, in manageable chunks.
It’s worth noting immediately that match_all is not typically how applications retrieve huge amounts of data efficiently — it’s simply the request that says “don’t filter anything.” What actually gets returned to the client is still limited and paginated like any other search, a detail we’ll unpack fully in Chapter 5.
2Why Does This Concept Exist?
Every technology exists to solve a real, painful problem. Here is the one match_all solves.
Elasticsearch’s query language is built almost entirely around describing conditions — match this word, filter by that range, exclude these values. But there are many completely legitimate moments where you don’t want any condition at all: you simply want to look at, count, or process the full, unfiltered set of documents in an index.
The Core Problem
Every meaningful query language needs a way to express “no condition” cleanly, rather than forcing users to invent an artificial, always-true filter just to retrieve everything.
The match_all query solves this directly, providing a clean, explicit, and honest way to say “I want everything,” rather than resorting to awkward workarounds like matching on a wildcard or an always-true range condition, which would be both confusing and unnecessarily expensive to evaluate.
Because match_all applies no actual matching logic, it is also one of the cheapest queries Elasticsearch can execute per document — there’s no text analysis, no scoring calculation beyond a fixed constant, and no field comparison happening at all.
match_all also plays a quiet but important supporting role inside more complex queries. It’s frequently used as a neutral starting point within a broader boolean query — for example, combined with filters that narrow results by exact criteria without affecting relevance scoring, a pattern explored further in Chapter 6.
3Architecture and Components
Where match_all fits within Elasticsearch’s broader query execution model.
Every search request in Elasticsearch, no matter how complex, ultimately produces a set of matching documents and, for each one, a relevance score. match_all fits into this same pipeline, just with the simplest possible logic plugged into the matching step.
Query Clause
The part of a search request describing matching logic — match_all is the simplest such clause.
Scoring Function
Normally calculates relevance based on term frequency and other factors; for match_all it’s a fixed constant.
Boost Parameter
An optional multiplier that can adjust match_all’s otherwise flat score, useful in compound queries.
Result Pagination
Controls how many of the matched documents are actually returned per request, same as any other query.
graph TD
A[match_all query received] --> B[No field comparison needed]
B --> C[Every document in the shard qualifies]
C --> D[Assign fixed score of 1.0 to each]
D --> E[Apply pagination — return only requested slice]
Think of a bouncer at a free, open-entry community event, standing at the door simply waving everyone through without checking a single ID. Compare that to a bouncer at an exclusive party checking names against a specific guest list — this second bouncer represents an ordinary, filtering query, while the first represents match_all.
Because there’s no filtering logic to evaluate, match_all queries touch every shard the same way a normal search would — they still fan out across the index’s shards, but the work each shard does per document is minimal, since there’s nothing to check beyond “does this document exist.”
4How It Works Internally
What actually happens inside a shard when a match_all request arrives?
When a shard receives a match_all query, it doesn’t need to consult the inverted index to determine which documents qualify, because the answer is always “all of them.” Instead, it can rely on a much simpler internal mechanism that essentially enumerates every live document currently stored in that shard.
Skip Field Matching
No specific field or term needs to be checked, since the query imposes no conditions.
Enumerate Live Documents
The shard walks through all currently non-deleted documents in its segments.
Assign a Constant Score
Each matched document receives the same fixed relevance score, typically 1.0 unless boosted.
Return the Requested Page
Only the specific slice of results requested (based on pagination settings) is actually sent back.
Many beginners assume match_all returns the entire index’s contents in one response. In reality, it returns only a default page (commonly the first ten documents) unless explicitly told otherwise, exactly like any other search request.
Because it involves no text analysis or scoring computation of any real substance, match_all is computationally lightweight per document, though the total cost still scales with how many documents are actually asked for and returned in the response, just as with any query.
5Data Flow and Lifecycle
Following a match_all request through the cluster, from request to response.
sequenceDiagram
participant Client
participant Coordinator as Coordinating Node
participant ShardA as Shard A
participant ShardB as Shard B
Client->>Coordinator: Search request: match_all
Coordinator->>ShardA: Forward query
Coordinator->>ShardB: Forward query
ShardA-->>Coordinator: All local documents, score 1.0 each
ShardB-->>Coordinator: All local documents, score 1.0 each
Coordinator->>Coordinator: Merge, apply pagination limit
Coordinator-->>Client: Return requested page of results
This is an important detail: even though match_all imposes no filtering, it does not skip the normal distributed search process. Every relevant shard is still contacted, and the coordinating node still merges their results and applies whatever pagination the client requested, exactly as it would for any other search.
Default Page Size
Without explicit pagination settings, a match_all search typically returns only the first ten results.
from / size Pagination
Standard offset-based pagination works with match_all just as it does with any other query.
Deep Pagination Limits
Very deep offset-based pagination becomes inefficient, regardless of the query being match_all.
Scroll / search_after
For retrieving genuinely large volumes of documents, dedicated deep-pagination mechanisms are preferred.
In other words, match_all changes which documents are eligible to be returned — namely, all of them — but it doesn’t change how many are actually returned in a single response, nor does it bypass the general performance considerations that apply to retrieving large result sets from any query.
6Common Uses and Real-World Examples
How match_all actually shows up in everyday Elasticsearch usage.
Browsing or Exploring an Index
A developer new to a dataset often runs a simple match_all query first, just to see what a handful of documents actually look like, before writing more specific, targeted queries.
Counting Total Documents
Applications wanting a quick total document count for an index commonly pair match_all with a request configured to return only the count, skipping the actual document contents entirely.
Combining with Filters in a Bool Query
Rather than being used entirely alone, match_all is frequently placed inside a boolean query alongside filter clauses, so results are narrowed by exact criteria without those filters affecting relevance scoring.
Testing and Development
Engineers setting up a new index during development often use match_all as a quick sanity check to confirm that recently indexed documents are present and correctly formatted.
| Scenario | Query Approach | Why |
|---|---|---|
| Exploring a new index | match_all | See sample documents with no filtering assumptions |
| Finding documents matching text | match / multi_match | Requires analysis and relevance scoring |
| Filtering by exact category, scoring by relevance | bool with match_all + filter | Keeps filtering separate from scoring |
| Exporting an entire index | match_all with scroll or search_after | Efficient deep pagination over large result sets |
7Advantages, Disadvantages and Trade-offs
Simplicity has its benefits — and its very real limitations.
Advantages
- Extremely simple and easy to understand, even for complete beginners.
- Computationally cheap per document, since no matching logic needs to be evaluated.
- Useful as a neutral starting point inside more complex boolean queries.
- Great for quick data exploration, sanity checks, and total document counts.
- Behaves predictably and consistently across every index and mapping.
Disadvantages / Trade-offs
- Provides zero filtering, making it unsuitable for any real search requirement on its own.
- Flat scoring gives no meaningful way to prioritize any document over another.
- Naively used for retrieving very large volumes of data, it still faces normal pagination limits.
- Overused as a “just get everything and filter in the application” habit, it can waste bandwidth and effort better spent letting Elasticsearch filter server-side.
The trade-off here is almost philosophical: match_all’s entire value comes from doing nothing special at all. That makes it perfect for genuinely “give me everything” situations, and completely wrong for anything resembling a real search requirement.
8Security Considerations
A query with no filtering deserves extra thought about who can run it.
Because match_all deliberately imposes no restrictions on which documents are eligible, it can, if permissions are misconfigured, become an easy way for someone to retrieve far more data than they should ever be able to see — including documents they’d never manage to stumble upon through normal, filtered searching.
Document-Level Security
Ensure permission restrictions apply consistently, even when a user issues a completely unfiltered query.
Restrict Broad Read Access
Limit which roles are permitted to run unrestricted queries against sensitive indices at all.
Rate Limit Bulk Exports
Watch for repeated, large-scale match_all-style requests that might indicate a data exfiltration attempt.
Audit Broad Queries
Log unfiltered, full-index queries against sensitive data for later review, just as you would for exports.
Assuming a query is inherently “safe” simply because it isn’t searching for anything specific. An unfiltered match_all can actually be one of the most exposing queries possible, precisely because it holds nothing back.
9Monitoring, Logging and Metrics
What’s worth watching when match_all shows up in production traffic.
Unfiltered Query Frequency
A sudden spike in match_all-style queries against a sensitive index is worth investigating.
Deep Pagination Attempts
Repeated requests for very high page offsets often indicate an inefficient bulk retrieval pattern.
Response Payload Size
Tracks how much data unfiltered queries are actually pulling out of the cluster over time.
Scroll / search_after Usage
Confirms whether large exports are using efficient, dedicated pagination mechanisms as intended.
Since match_all is so lightweight per document, monitoring it is less about protecting cluster performance and more about protecting data — watching for patterns that suggest excessive, unfiltered access to sensitive information.
10Design Patterns and Anti-patterns
Sensible ways to use match_all, and mistakes worth avoiding.
Filter-Only Bool Query Pattern
A proven pattern wraps match_all inside a boolean query’s “must” clause, paired with one or more “filter” clauses for exact criteria, keeping relevance scoring neutral while still narrowing results precisely by category, date range, or status.
Efficient Full Export with search_after
When genuinely exporting an entire index’s contents, pairing match_all with search_after-based pagination (rather than deep offset-based from/size) keeps the operation efficient even for very large datasets.
Problem
Using match_all combined with deep, offset-based pagination (large “from” values) to page through an entire large index sequentially.
Why It’s Harmful
Offset-based pagination requires Elasticsearch to compute and discard all preceding results internally before returning the requested page, becoming increasingly expensive and slow as the offset grows.
Correct Approach
Use search_after or a scroll-style mechanism designed specifically for retrieving large volumes of documents efficiently, rather than relying on ever-increasing offsets.
Problem
Defaulting to match_all and then filtering results within the application code, instead of expressing the actual filtering criteria directly in the Elasticsearch query.
Why It’s Harmful
This wastes network bandwidth transferring documents that will simply be discarded, and forfeits Elasticsearch’s own highly optimized filtering capabilities in favor of slower, manual filtering elsewhere.
Correct Approach
Express known filtering criteria directly as query or filter clauses, reserving match_all specifically for situations where no filtering is genuinely intended.
11Best Practices and Common Mistakes
Practical, field-tested guidance for using match_all day to day.
Reserve it for genuinely unfiltered needs
Use match_all only when you truly want every document, not as a lazy default for every query.
Pair with filters when narrowing is needed
Combine match_all with explicit filter clauses inside a bool query rather than filtering client-side.
Use proper deep pagination for exports
Rely on search_after or scroll-style approaches for retrieving large volumes, not deep from/size offsets.
Apply access control consistently
Ensure permission restrictions apply the same way to match_all as they do to any other query type.
When exploring a new or unfamiliar index for the first time, start with a small match_all request limited to just a handful of results, purely to understand the document shape, before writing more targeted queries.
A frequent beginner mistake is assuming that using match_all somehow bypasses normal search infrastructure or costs nothing at all. While it is cheap per document, requesting a very large number of matched documents in one response still carries real network and memory cost, just like any other large result set.
Another common mistake is forgetting that match_all still respects an index’s usual document limits and mapping behavior — deleted documents, for example, are correctly excluded, since match_all only ever matches currently live, non-deleted documents.
12Frequently Asked Questions
Quick, direct answers to the questions beginners ask most often about match_all.
No. Like any other query, it’s still subject to normal pagination, typically returning only the first ten documents by default unless configured otherwise.
Because there’s no specific criteria being matched against, there’s nothing meaningful to compare documents on, so Elasticsearch assigns a flat, equal score to every one.
Functionally very similar — many clients default to match_all automatically when no query is specified, since “match everything” is the natural, sensible default behavior.
Yes, it’s commonly used inside a boolean query alongside filter clauses, which narrow the results by exact criteria without affecting the neutral relevance scoring.
It’s the right starting query, but should be paired with an efficient deep-pagination mechanism like search_after rather than simple offset-based pagination for large exports.
No, since it doesn’t inspect any specific field, it works identically regardless of how fields in the index happen to be mapped.
13Summary and Key Takeaways
The match_all query is Elasticsearch’s simplest possible way of saying “don’t filter anything” — a flat, neutral request that treats every document as equally relevant. Despite, or perhaps because of, its simplicity, it plays a genuinely useful role in exploring data, counting documents, building filter-only queries, and exporting entire indices, all while still respecting the same pagination and access-control rules that govern every other query in the system.
Key Takeaways
- match_all matches every document — with no filtering conditions and a flat, equal relevance score.
- It’s the cheapest query per document — no field comparison or meaningful scoring calculation is performed.
- It still respects normal pagination — it does not return an entire index’s contents in one response.
- It’s commonly paired with filters — inside a bool query, to narrow results without affecting scoring.
- Large exports need proper deep pagination — search_after or scroll, not deep offset-based paging.
- Security still applies fully — unfiltered queries can expose more data than expected if permissions are misconfigured.
- It’s ideal for exploration and sanity checks — but never a substitute for genuine, targeted search criteria.