|

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 (like match)
  • filter: cheap constraints that don’t care about scoring
  • must_not: exclude certain docs
  • should: 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.”

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *