To understand a wildcard query, we first need to understand what Elasticsearch normally does when you search. Most of the time, when you run a term query or a match query, Elasticsearch is looking for an exact match against entries in its internal dictionary of known values (we’ll get to exactly what that dictionary is in the next chapter). You give it a precise value — "laptop", "USA", "ERR_404" — and it either finds documents containing that exact value, or it doesn’t.

A wildcard query breaks that exactness requirement on purpose. It lets you write a search pattern using two special placeholder characters: the asterisk *, which means “match zero or more of any characters here,” and the question mark ?, which means “match exactly one character of any kind here.” So a wildcard pattern like "lap*" matches “laptop,” “lapse,” and “lap” itself, because the asterisk happily absorbs whatever comes after “lap,” including nothing at all. A pattern like "te?t" matches “test” and “text,” but not “teest,” because the question mark insists on exactly one character in that position, no more, no less.

It’s worth being precise about where wildcard queries sit in Elasticsearch’s broader family of pattern-matching tools, because beginners frequently reach for wildcard when a different, better-suited tool exists. There’s the prefix query, which only matches values starting with a given string (a narrower, faster special case of a trailing wildcard). There’s the regexp query, which supports full regular expression syntax — far more powerful than wildcard’s two simple placeholders, but also far more expensive to execute. And there’s match_phrase_prefix, designed specifically for autocomplete-style “as-you-type” searching over analyzed text. The wildcard query sits in the middle of this family: more flexible than a plain prefix match, but far simpler — and generally cheaper — than a full regular expression.

To make this concrete, imagine you’re searching a product catalog. If a product’s SKU field holds the value "SKU-88213-RED", a wildcard query for "SKU-882*" will match it — the asterisk absorbs “13-RED” and everything works as you’d expect. This is enormously useful for exactly the kind of “I remember part of it” search scenario our librarian analogy described: partial SKU lookups, partial hostname matches in infrastructure monitoring, partial email domain searches, and pattern-based log analysis are all classic, legitimate uses of the wildcard query — which is exactly why it’s worth understanding thoroughly rather than avoiding altogether.

It’s also worth being clear about what a wildcard query is not. It is not a general “search anywhere inside this value” tool the way a database’s LIKE '%value%' operator might feel — although, with an asterisk at both ends, it can approximate that behavior. It is not aware of word boundaries, synonyms, or stemming the way a proper full-text match query is; a wildcard pattern of "run*" will match the literal term “runner” but has no built-in concept that “running” and “ran” are related forms of the same word the way analyzed full-text search does. And it is not inherently ranked by relevance in any sophisticated sense — a document either contains a matching term or it doesn’t, which is precisely why wildcard clauses are so often placed in a filter context rather than a scoring query context within a larger compound query, a distinction we’ll return to later in this article.

At its simplest, a wildcard query names a field to search and a value containing your pattern with * and/or ? placeholders. Beyond that minimal shape, several optional parameters shape both correctness and performance:

One architectural fact matters more than any single parameter: which field type you run a wildcard query against changes its behavior completely. Against a keyword field, the wildcard pattern is compared against the field’s single, complete, unmodified stored value — exactly as the field’s raw string looked in the source document. Against an analyzed text field, the pattern is instead compared against each individual token produced by that field’s analyzer — meaning a text field containing “Wireless Gaming Mouse” doesn’t store that phrase as one unit, it stores three separate lowercase tokens: “wireless,” “gaming,” “mouse.” A wildcard pattern like "gam*" would match the “gaming” token, but a pattern like "wireless gam*" — containing a literal space — would never match anything at all, because no single token contains a space. This single fact trips up more engineers than any other aspect of the wildcard query, and we’ll return to it repeatedly throughout this article.

It’s also worth knowing that the field mapping itself, not just the query, influences how much work a wildcard search will require. A field mapped as keyword with "index": true stores its values in a way that’s directly searchable by the wildcard automaton; a field with indexing disabled entirely cannot be wildcard-searched at all, regardless of what the query looks like, since there’s no term dictionary for Lucene to walk in the first place. This is a useful diagnostic starting point whenever a wildcard query mysteriously returns nothing: before questioning the pattern syntax, it’s worth confirming the target field is actually indexed and of a type wildcard queries can operate on.

flowchart LR
    A["Pattern: lap*top"] --> B{Target field type?}
    B -- keyword --> C["Compared against the ENTIRE stored value
e.g. 'laptop-charger' as one string"]
    B -- text --> D["Compared against EACH individual token
produced by the field's analyzer"]
    C --> E[Match or no match, whole-value]
    D --> F["Match or no match, per token
(no single token can contain a space)"]
        

To really understand why wildcard queries can be slow, we need to understand the data structure they search against: the terms dictionary (sometimes called the term index), which lives inside Elasticsearch’s underlying search library, Lucene. When Elasticsearch indexes a field, it doesn’t store your data as a simple list of documents — it builds an inverted index: essentially, a sorted, alphabetized dictionary of every unique term that has ever appeared in that field, with each term pointing to the list of documents containing it. This is precisely why exact-match searches (like a term query) are extremely fast: finding a single known word in a sorted dictionary is a well-understood, efficient operation — similar to how you’d flip almost directly to the right page in a physical dictionary rather than reading every page from the start.

A wildcard query, however, doesn’t know one specific term to look up. It has to figure out which of the potentially millions of terms in that sorted dictionary actually match your pattern. Internally, Lucene converts your wildcard pattern into a structure called an automaton — think of it as a small state machine that can very efficiently answer the yes/no question “does this specific term match my pattern?” for any term you feed it. The genuinely clever part of Lucene’s implementation is that it doesn’t naively test every single term in the dictionary one by one; because the dictionary is sorted alphabetically, Lucene can use the automaton to intelligently skip large stretches of terms that couldn’t possibly match, jumping ahead rather than checking each one individually.

The scale of this difference is not subtle. On a field with a few thousand unique terms, a leading wildcard might barely be noticeable. On a field with tens of millions of unique terms — a common reality for fields like full URLs, free-text log messages, or user-generated IDs — a leading wildcard query can force Lucene to evaluate every single one of those millions of entries for every single query execution, on every shard, for every search request. This is precisely why Elasticsearch, by default, actually disallows leading wildcards through the standard query_string search syntax (via the allow_leading_wildcard setting, defaulting to true historically but increasingly discouraged), and why experienced engineers treat any pattern starting with * or ? as a deliberate, carefully considered decision rather than a casual default.

There’s one more internal detail worth understanding: the distinction between running a wildcard clause in query context versus filter context. In query context (the default, when a wildcard clause sits directly at the top level of a search request), Elasticsearch computes a relevance score for every matching document, which adds a small amount of extra computation on top of the matching work itself. In filter context (when the same clause is nested inside a bool query’s filter array), Elasticsearch skips scoring entirely and only needs a yes/no answer per document — because most wildcard use cases genuinely don’t need nuanced relevance ranking (a SKU either matches the pattern or it doesn’t), placing wildcard clauses in filter context is both more semantically honest and measurably cheaper. Filter-context clauses are also eligible for Elasticsearch’s filter cache in a way that scored queries typically are not, though as noted earlier, the sheer variety of distinct wildcard patterns in practice still limits how often that cache actually pays off compared to a fixed, repeated exact-match filter.

Let’s trace a wildcard query’s complete journey, from the moment a request leaves a client application to the moment ranked results come back, because this full-circle view is what lets you reason about latency and load rather than treating the query as a black box.

This lifecycle also explains why wildcard query cost scales with two independent factors that are easy to conflate: the number of documents in your index, and the cardinality (the count of distinct unique values) of the specific field you’re searching. A field with low cardinality — say, a status field with only five possible values — will always be fast to wildcard-search regardless of how many documents exist, because the term dictionary itself is tiny. A field with extremely high cardinality — like a raw log message field or a UUID field — can be slow to wildcard-search even on a relatively small index, because the term dictionary itself is enormous. Understanding cardinality, not just document count, is the real key to predicting whether a given wildcard query will be fast or slow in your specific dataset.

It’s also worth understanding why merging results across shards (step 6) is itself a meaningful part of the cost equation for high-fan-out wildcard searches. Because each shard independently determines its own top matches before the coordinating node merges them, a wildcard pattern that matches an unusually large number of distinct terms can produce a correspondingly large candidate result set on every shard, increasing both the memory pressure of holding those intermediate results and the network cost of shipping them back to the coordinating node for the final merge. This is a second, often-overlooked reason that broad, loosely-anchored wildcard patterns cost more than narrow, well-anchored ones — the expense isn’t confined to the term-dictionary walk alone, it compounds through every later stage of the request lifecycle as well.

There’s a broader trade-off worth naming explicitly: wildcard queries optimize for recall — catching every possible match for a shape, even loosely — at the expense of precision and relevance nuance. A full-text match query, by contrast, is built to rank results by how well they satisfy a natural-language intent, factoring in term frequency, field length, and other relevance signals a wildcard query simply doesn’t consider. This means wildcard queries are best suited to situations where the user or system genuinely wants “everything that fits this shape, and I’ll sort through it myself” — an operator investigating an incident, an analyst hunting for a pattern, a catalog lookup with a known partial code — rather than situations where “give me the single best answer” is the actual goal, which is better served by full-text search’s richer relevance model.

The primary security concern with wildcard queries isn’t unauthorized data access in the traditional sense — it’s resource exhaustion, sometimes framed as a search-layer denial-of-service risk, which becomes a genuine concern the moment any part of a wildcard query’s pattern is influenced by untrusted, end-user input.

Consider a public-facing search box that passes whatever a user types directly into a wildcard query against a high-cardinality field, such as a free-text product description. A well-intentioned user searching for "*phone*" triggers exactly the expensive, full-dictionary-scan scenario described in Chapter 3. Now imagine this isn’t accidental — a malicious actor, aware of this behavior, deliberately submits a flood of concurrent leading-wildcard queries against your most expensive, highest-cardinality field, specifically to consume CPU and I/O across every shard simultaneously. Unlike a classic network-layer denial-of-service attack, this doesn’t require unusual traffic volume — a handful of carefully chosen, expensive queries per second can meaningfully degrade search latency for every other legitimate user on a shared cluster.

A second, related concern is input validation at the application layer, sitting in front of Elasticsearch itself. Because wildcard syntax uses ordinary characters (* and ?) that a user might type incidentally, applications that build wildcard queries programmatically from raw user input should validate or sanitize that input — for example, escaping literal asterisks a user intended as plain text, capping the number of wildcard characters permitted per query, and rejecting or de-prioritizing patterns that resolve to a leading wildcard — rather than assuming every character a user types is safe to drop directly into a query pattern unexamined.

It’s worth stressing that these defenses are cheap to implement and cost almost nothing for legitimate users, which is exactly why they’re considered standard practice rather than an optional hardening step reserved for high-security environments. A genuine user searching for a product they half-remember is rarely inconvenienced by a rule requiring three literal characters before a wildcard — in practice, most real searches already satisfy that constraint naturally. The rule exists specifically to close off the narrow, deliberately pathological cases that cost the most and benefit legitimate users the least, which is the same risk-versus-friction calculation behind most well-designed rate limits and input constraints across production systems generally, not something unique to Elasticsearch.

Because a wildcard query’s cost depends so heavily on pattern shape and field cardinality — factors invisible from the query’s JSON alone — production teams rely on a specific set of tools to observe actual, measured cost rather than guessing at it.

A mature monitoring setup typically alerts not just on raw latency, but on the combination of high latency and a wildcard clause appearing in the slow log’s captured query body — because a slow term-level query on a low-cardinality field usually points to a different underlying problem (like general cluster load), while a slow wildcard query specifically points toward exactly the pattern-shape and cardinality issues this article has walked through, and is fixable at the query-design level rather than requiring more hardware.

Beyond reactive monitoring, some teams build a lightweight proactive check into their deployment pipeline: before a new field is exposed to wildcard-based search in a user-facing feature, an automated check queries that field’s cardinality via the aggregation mentioned above and flags it if the count exceeds a predefined threshold, prompting a design review before the feature ships rather than after a production incident reveals the problem. This shift-left approach mirrors how many teams already treat other performance-sensitive design decisions — catching an expensive query pattern during code review is dramatically cheaper than diagnosing it under production load, especially for a query type like wildcard whose cost is so sensitive to data characteristics that don’t fully reveal themselves until real-world scale is reached.

Proven Patterns

Anti-patterns to Avoid

Wildcard queries show up across a wide range of production systems — precisely the systems where users legitimately know only part of what they’re looking for, or where operators need flexible ad-hoc pattern matching over operational data.

A wildcard query lets you search Elasticsearch using simple pattern shapes — * for “anything, including nothing,” and ? for “exactly one character” — matched against the terms already sitting in a field’s inverted index, not against raw document text scanned fresh at query time. Its real-world cost is governed almost entirely by two factors: whether the pattern has a usable literal prefix that lets Lucene skip large sections of the sorted term dictionary, and how many distinct unique terms (cardinality) exist in the field being searched. Understanding both of these is what separates a wildcard query that returns in milliseconds from one that quietly becomes the slowest, most resource-hungry query on your entire cluster.

None of this requires memorizing every internal detail of Lucene’s automaton implementation. What it requires is the mental model this article has built, chapter by chapter: think of the term dictionary as a sorted shelf of books, think of a literal prefix as the section label that lets you skip straight to the right shelf, and remember that a pattern with nothing to skip to means checking every single book by hand. Design your fields and your patterns with that shelf in mind, and wildcard queries become exactly what they should be — a genuinely useful, predictable tool rather than a hidden performance trap.

The engineers who get the most value out of wildcard queries over the long run tend to share a common habit: they ask “what shape is this search, and what shape is this field?” before they ever write the query itself. A trailing-wildcard pattern against a moderate-cardinality keyword field is almost always safe by default. A leading-wildcard pattern against a high-cardinality free-text field almost always deserves a second look — either a redesign at index time, a stricter guard at the application layer, or a deliberate, informed decision that the cost is acceptable for this particular, lower-traffic use case. That single habit of asking the question first is, in practice, the entire difference between wildcard queries as a reliable production tool and wildcard queries as a recurring incident.