Magnifying glass, book and buddy: LIKE, full-text and vectors in plain words

Problem

In "SQL isn't dying, it's mutating" I wrote that SQL isn't dying, it's mutating. Text search shows this best, because that is where most has changed in recent years.

The example from my talks: we have a database of 60 articles about coffee, written in Polish. Four of them (IDs 1–4) are texts for a professional barista: pressure profiling, water chemistry, coffee distribution in the portafilter, refractometer and extraction yield. The other 56 are noise: coffee history, recipes, growing regions. The barista types a question: "Jak prawidłowo parzyć kawę?" ("How do I brew coffee properly?").

The titles of the articles they are looking for read, for example, "Advanced extraction: pressure profiling and flow control". None of them contains "brew" or "coffee" in the form used in the question. A human sees immediately that it is about the same thing. The SQL query doesn't.

A correction to myself: on the "Failure in practice" slide I showed results like "247 articles, most of them irrelevant". Those were illustrative numbers, and the demo set had 60 rows. Below are numbers computed on the actual demo data.

How it works

In my talk on SQL and AI I used an analogy that worked better in the room than any definition. We are looking for information about "combustion vehicles".

• LIKE and regex are a magnifying glass. We look at every letter. We find "vehicle", but not "car", "auto" or "automobile". We see characters, not meaning.
• Full-text is a book with an index. We have an alphabetical index that knows word forms, so we find "vehicle" and "vehicles". But "car" is a different entry in the index. We have to know what to look for.
• Vectors are a buddy who gets it. We say "something about those four wheels with an engine", and the buddy answers: "Ah, you mean cars." They understand the intent, even if we use different words.

The first two are syntactic search, the third is semantic search.

I came up with this analogy before the talk.

Step by step

The queries stay in Polish, exactly as in the demo, because the data is Polish. That is part of the lesson: Polish inflection makes the magnifying glass even weaker.

Magnifying glass: LIKE

The query from the SQL Server 2025 demo, the same pattern on the title and the body:

T-SQL, SQL Server 2025 (outside Databricks)

SELECT id, title FROM dbo.ArticlesAboutCoffee
WHERE body COLLATE Latin1_General_CI_AS LIKE N'%jak%prawidłowo%parzyć%kawę%';

Result: 0 rows in the body and 0 in the titles. For comparison, title LIKE N'%kawa%' returns 18 titles, but misses 10 titles that use "kawy", "kawę", "kaw" or "kawowe" (other forms of "coffee"). The magnifying glass doesn't know inflection.

On Databricks we can do the same in SQL with no setup at all. The notebook for this post (code/lupa_ksiazka_kumpel.sql) doesn't need the talk data: it generates 12 short synthetic coffee articles, where IDs 1–4 are again texts for a professional barista and the other 8 are noise.

✓ Works on Free Edition

SELECT id, title
FROM coffee_articles
WHERE body ILIKE '%parzyć%' OR title ILIKE '%parzyć%';

In the lab (29 Sept 2026) this query returned 0 rows, just like the full pattern '%jak%prawidłowo%parzyć%kawę%'. The bodies contain "parzenia" and "parzona" (other forms of "brew"), but not "parzyć". Inflection hurts the same way as on SQL Server: title ILIKE '%kawa%' matched 1 title out of 12, and title RLIKE '(?i)kaw(a|y|ę|owe)' matched 4.

Lab result (Databricks, 29.09.2026): ILIKE '%kawa%' finds 1 title out of 12, the regex with word forms finds 4, and none of the barista articles (IDs 1–4) has "coffee" in its title in any form.

A better lens: regex

Regex lets us search for whole words and lists of variants:

✓ Works on Free Edition

SELECT id, title,
       regexp_extract(body, '(?i)(espresso|aeropress|french press|chemex|v60|moka)', 1) AS first_method
FROM coffee_articles
WHERE body RLIKE '(?i)(espresso|aeropress|french press|chemex|v60|moka)';

My demo script also had a query that looked reasonable and returned everything:

T-SQL, SQL Server 2025 (outside Databricks)

-- BŁĄD: pusta alternatywa na końcu dopasuje każdy tekst
WHERE REGEXP_LIKE(body, N'(jak|prawidlowo|parzyc|kawe|)', 'i')

The last | before the closing bracket adds an empty alternative, and the empty string matches any text. On 60 articles that is 60 hits. With the empty alternative removed, 12 are left, including accidental hits on "jak" inside other words.

On Databricks the same mistake looks the same, only with RLIKE instead of REGEXP_LIKE. In the lab (29 Sept 2026), on the 12 synthetic articles, the pattern with the empty alternative matched 12 of 12 rows, and without it 0. These short texts don't contain any of those four words spelled without Polish diacritics, so the difference is even more visible.

Lab result (Databricks, 29.09.2026): a single | turns 0 hits into 12 of 12, with no error and no warning.

Book: full-text search

Full-text search in SQL Server needs some preparation: a catalog, a unique index on the key, and a full-text index with Polish as the language (1045).

T-SQL, SQL Server 2025 (outside Databricks)

CREATE FULLTEXT CATALOG CoffeeCat;
CREATE UNIQUE INDEX UX_ArticlesAboutCoffee_Id ON dbo.ArticlesAboutCoffee(id);
CREATE FULLTEXT INDEX ON dbo.ArticlesAboutCoffee
  (title LANGUAGE 1045, body LANGUAGE 1045)
  KEY INDEX UX_ArticlesAboutCoffee_Id ON CoffeeCat
  WITH CHANGE_TRACKING AUTO;

SELECT TOP 10 d.id, d.title, k.rank
FROM FREETEXTTABLE(dbo.ArticlesAboutCoffee, (title, body), N'jak prawidłowo parzyć kawę') AS k
JOIN dbo.ArticlesAboutCoffee d ON d.id = k.[KEY]
ORDER BY k.rank DESC;

FREETEXTTABLE splits the question into words and looks for their forms, and the rank column tells us about relevance. That is a big step up from the magnifying glass. But we are still searching for words: the article on pressure profiling doesn't contain "parzyć" in any form.

Databricks SQL has no equivalent of CONTAINSTABLE. Full-text search there comes from AI Search in FULL_TEXT or HYBRID mode, but in a rehearsal on 15 Sept 2026 FULL_TEXT was a preview disabled by default on a fresh workspace. I will come back to this in the part comparing the two platforms.

Buddy: similarity of meaning

The simplest way to see the "buddy" at work on Databricks is the ai_similarity function. It compares two texts and returns a similarity score, with no index and no model of your own.

✓ Works on Free Edition

SELECT id, title,
       ai_similarity(body, 'Jak prawidłowo parzyć kawę?') AS score
FROM coffee_articles
ORDER BY score DESC
LIMIT 5;

In the lab (29 Sept 2026) the buddy did not do as well as in the analogy. For "Jak prawidłowo parzyć kawę?" the top places went to "Historia kawy" (coffee history, 0.679), "Regiony kawowe: Brazylia" (coffee regions: Brazil, 0.671) and "Cold brew na upały" (0.628). Of the four barista articles, only "Chemia wody w kawiarni" (water chemistry in the café) made the top five (ID 2, fourth place, 0.626).

Lab result (Databricks, 29.09.2026): the barista's literal question ranks texts that simply talk a lot about coffee at the top, not the ones the barista is looking for.

Only when the question spelled out the intent, 'Profesjonalne techniki parzenia kawy dla zaawansowanych baristów' ("professional brewing techniques for advanced baristas"), did three barista articles (IDs 1, 2 and 3) make the top five. Brazil was still first (0.695).

Lab result (Databricks, 29.09.2026): a better-described intent pulls three of the four right articles into the top five, but all scores sit in a narrow 0.61–0.69 band.

My takeaway is that the buddy understands more than the magnifying glass, but on short Polish texts and a one-sentence question it is no oracle. The result depends on the model and on how we phrase the question, so it pays to check the ranking on your own examples before building on it.

On a small table this is enough. With thousands of documents, computing similarity for every row on every question stops making sense, and then we need embeddings stored in a table and an index.

Pitfalls

• Collation and diacritics. Latin1_General_CI_AS is case-insensitive but accent-sensitive, so "parzyc" won't find "parzyć". Polish_100_CI_AI ignores accents. The result of the same LIKE depends on the column's collation.
• An empty alternative in a regex. (a|b|) matches everything. The mistake doesn't throw an exception; it returns the whole table.
• A leading %. LIKE '%kawa%' can't use a B-tree index, so on a big table it is a full scan.
• Full-text has no synonyms. The index knows "vehicle" and "vehicles", but "car" is a different word to it. A synonym list (thesaurus) has to be maintained by hand.
• Vectors always return something. Vector search returns the nearest neighbours even when the question has nothing to do with the data. A question about the city of Bielsko-Biała in a coffee database will also get its "best" five articles.
• The embedding model and the language. databricks-gte-large-en is an English model. In an early test before the workshop, a Polish paraphrase scored 0.611 and an unrelated sentence 0.574. That margin is small, so for Polish text it pays to test the model on your own examples. In the lab (29 Sept 2026) ai_similarity gave the whole top five scores between 0.61 and 0.69 for both questions, and both times the article about Brazil, which has nothing to do with brewing, ranked high.

When NOT to use it

• Vectors for codes, e-mails, numbers. If we know the pattern (^[A-Z]{2}\d{4}$), a regex gives a deterministic and cheap result. A buddy who "roughly" matches an invoice number is a bad idea.
• LIKE for questions about meaning. Adding more OR LIKE clauses with synonyms quickly becomes unmaintainable.
• Full-text when you can't maintain it. A full-text index is one more object to administer. On a small table ILIKE is sometimes enough.

See it run

The recording walks through the notebook, from creating the table through ILIKE and RLIKE to both ai_similarity queries.

The full notebook is in the code/ folder (lupa_ksiazka_kumpel.sql), together with the T-SQL version for SQL Server.

Summary

• The magnifying glass (LIKE, regex) sees letters, the book (full-text) sees words and their forms, the buddy (vectors) sees meaning.
• On 60 coffee articles, LIKE for "jak prawidłowo parzyć kawę" returns 0 rows, and %kawa% misses 10 titles with a different form of the word.
• A regex with an empty alternative matches everything. Check the hit count before you trust the result.
• In the lab, ai_similarity put only one of the four barista articles in the top five for the literal question. The buddy also needs a well-phrased question and a check on your own data.

As of: 29 Sep 2026