Elasticsearch Queries – Part 1: Queries and Filters
When I first got to know Elasticsearch, I told myself: “Well, this is just another database… right?”
But I was wrong. Elasticsearch is actually different. It kind of feels like a mix between a search engine and a database.
To be honest, I’m still not very comfortable with it myself 🙂
But in this post—which is the first part of a series—I’m going to explain how I’ve used Elasticsearch queries in my projects so far.
Also, it’s kind of like notes for my future self (and I hope it’ll be useful for you too).
The Mental Model
At its core, Elasticsearch is built on a simple hierarchy:

If you come from SQL, think of an index like a table, a document like a row, and a field like a column.
But here’s the twist: Elasticsearch is more flexible. You don’t have to pre-define every column with a rigid schema. It’s happy to accept JSON documents on the fly.
That said, mapping matters.
Why Mapping Is Your Friend
Elasticsearch will happily “guess” the type of your fields if you don’t tell it. Sometimes it guesses right. Sometimes it doesn’t.
Example: you might think your order_id
is numeric, but ES might store it as text. That tiny mistake will later bite you when you want to sort or run numeric filters.
Rule of thumb: Always define the mapping for important fields. Treat it like setting the foundation before building a house.
Query vs Filter
Here’s where many beginners (my past self included) get confused.
- Query context is about relevance. ES assigns a score: “this document matches better than that one.” Great for search boxes, product searches, or anything where you rank results.
- Filter context is about constraints. You want exact matches or ranges, and you don’t care about scoring. Filters are super fast because they can be cached.
Think of it like this:
Query = “Which books are most relevant if someone types Harry Potter?”
Filter = “Only show me books in stock and cheaper than $20.”
When to Use Filter vs Match
Here’s how I decide in practice:
If someone types into a search bar → use match (query context), but if you’re slicing and dicing data in a dashboard or enforcing business rules → use filters.
Example 1 – Free-text Search
GET orders/_search { "query": { "match": {"customer": "sara"} } }
This looks for documents where the customer
field sounds like “sara.”
It’s not exact: it will also catch “Sara,” “Sarah,” or even “saraa.” That’s because ES tokenizes and analyzes the text. Perfect for when humans type messy input.
Example 2 – Exact Filters
GET orders/_search { "query": { "bool": { "filter": [ {"term": {"status": "paid"}}, {"range": {"total": {"gte": 100}}} ] } } }
This is like
WHERE status = 'paid' AND total >= 100
in SQL.
No scores, no fuzziness. Just raw constraints.
I use this style for reports, dashboards, or background jobs where relevance doesn’t matter — I just need the data.
Example 3 – Mixing Both
And here’s where Elasticsearch really shines: you don’t have to pick one or the other. You can mix.
GET orders/_search { "query": { "bool": { "must": {"match": {"customer": "sara"}}, "filter": {"term": {"status": "paid"}} } } }
This says: Find me all “Sara” orders, but only the ones that are already paid.
The match
makes sure we handle variations of “Sara” (scoring them by relevance), while the filter
makes sure we don’t waste time on unpaid orders.
Bool: The Backbone of Real Queries
Most queries I write in production aren’t a single match
or a single filter
. They’re a bool query — a combination of conditions that together shape what I want.
must
: things that affect scoring (likematch
)filter
: cheap constraints that don’t care about scoringmust_not
: exclude certain docsshould
: give extra points if something matches
Once you start using bool, ES stops feeling magical and starts feeling logical.
Wrapping Up
So in this first step, we covered:
- How Elasticsearch thinks about data (Index → Document → Field)
- Why mapping matters
- The difference between query (scoring) and filter (constraints)
- How to mix both with
bool
If you run these examples in your own cluster, you’ll already see the power of ES.
In the next part, we’ll dig deeper into text analysis: how ES tokenizes, what analyzers are, and why searching for “quick fox” might also find “the quickest fox.”