SQL Pattern Matching As A Beginner (LIKE, ILIKE, IN, BETWEEN)

#sql #postgres #database #beginners

Today was one of those SQL days where things didn’t feel flashy, but they finally felt useful.

Instead of just watching videos, I practiced how databases search text and filter ranges, the kind of SQL you’d actually write when querying real data.

This session focused on:

Pattern matching with LIKE and ILIKE
Using wildcards (% and _)
Filtering ranges with BETWEEN
Matching sets with IN

What I Learned Today

LIKE vs ILIKE (Case Sensitivity Matters)

At first glance, LIKE and ILIKE look the same but they’re not.

LIKE → case-sensitive

LIKE → case-insensitive

So for example:
If I wanted to get the names of every user that had the letter 'J' somewhere in their name (first, last and middle) and I used this query with LIKE.

SELECT name
FROM users
WHERE name LIKE 'J';

I might not get all the results as it would only pull entries with with capital 'J' which in most cases are just the first letters of the name.

On the other hand if I used the ILIKE to get all entries 'j'. It would pull any name that contains the letter J, whether capital or small

SELECT name
FROM users
WHERE email ILIKE 'j';

This feels safer when working with user-generated text like emails or names. ILIKE is usually what I would want when searching text written by humans. Giving space for errors and spontaneity of users.

Wildcards: % and _

This part clicked more today.

% → matches any number of characters

_ → matches exactly one character

Examples:

-- Emails ending with gmail.com
WHERE email ILIKE '%gmail.com';

-- Names with exactly 5 letters
WHERE name LIKE '_____';

This made me realize SQL isn’t “guessing” it’s matching patterns very literally.

BETWEEN (Ranges That Read Cleanly)

I used BETWEEN to filter date of birth (DOB) ranges, which felt very practical.

SELECT name, dob
FROM users
WHERE dob BETWEEN '1995-01-01' AND '2000-12-31';

This reads much cleaner than writing multiple comparisons.

One thing I learned:

BETWEEN is inclusive of both ends

That detail matters more than I expected.

** IN (Cleaner Than Multiple ORs)**

Instead of writing a needlessly long query with lots of conditions:

WHERE country = 'Nigeria' OR country = 'Ghana' OR country = 'Kenya'

You can write:

WHERE country IN ('Nigeria', 'Ghana', 'Kenya');

This makes queries:

Shorter
Easier to read
Easier to update later

These are small improvements, but they stack up quite quickly. Imagine someone were to specify getting countries from like 30 countries in that case. So I learnt how to make queries more efficient.

What I Practiced (Hands-On)

Today wasn’t about solving puzzles, it was about querying real-ish data.

Things I did:

Queried emails using LIKE and ILIKE
Filtered users by date of birth ranges
Used IN to match multiple values cleanly
Combined pattern matching with WHERE conditions

This felt closer to how SQL is actually used in production systems and I realized something fundamental for my growth:

This is how databases search user data. Emails, usernames, dates, categories, these are everyday SQL, not interview-only SQL. And honestly, this is where SQL started feeling less abstract.