SQL nie umiera, tylko mutuje

Skąd ta teza

Jesienią 2025 roku przygotowałem prelekcję „O SQL, AI i Przyszłość Baz Danych”. Plan był prosty: trzy akty, SQL, AI i bazy danych przyszłości. Im dłużej zbierałem materiał, tym mocniej wracało do mnie jedno zdanie, które ostatecznie trafiło na slajd:

„SQL nie umiera, tylko mutuje.”

Mówiłem o tym w Krakowie i w Bielsku-Białej na spotkaniach ze studentami, gdzie temat był prosty: czy warto jeszcze pisać w SQL-u i się go uczyć. Wychodzi na to, że warto, bo SQL ciągle żyje i ma się dobrze.

Nie jest to obrona SQL-a z sentymentu. To obserwacja z historii tego języka i z codziennej pracy na Databricks, gdzie AI coraz częściej wołamy dokładnie tam, gdzie wcześniej pisaliśmy zwykły SELECT.

Fundament: mówimy „co”, a nie „jak”

SQL jest językiem deklaratywnym. Piszemy, jaki wynik chcemy dostać, a silnik sam decyduje, jak go policzyć. Klasyczny przykład ze slajdu:

✓ Działa na Free Edition (na dowolnej tabeli z kolumnami name i salary)

SELECT name, salary
FROM employees
WHERE salary > 5000
ORDER BY salary DESC;

Nie ma tu pętli, indeksów ani kolejności odczytu plików. Dzięki temu optymalizator może zmienić sposób wykonania, a zapytanie zostaje to samo. Moim zdaniem to jest główny powód, dla którego SQL przetrwał ponad pół wieku zmian technologicznych: warstwa „co” jest oddzielona od warstwy „jak”, więc pod spodem można wymienić prawie wszystko.

Na labie (29.09.2026) uruchomiłem to zapytanie na syntetycznej tabeli employees z pięcioma wierszami. Wróciły trzy: 7300, 6250 i 5100, w tej kolejności. Pracownik z pensją 4999 odpadł na warunku salary > 5000, a o tym, jak silnik przeczytał dane, nie musiałem nic pisać.

Wynik z labu (Databricks, 29.09.2026): z pięciu wierszy zostały trzy z pensją powyżej 5000, posortowane malejąco, bez ani jednej linijki o tym, „jak” to policzyć.

Trochę historii, bo pomaga zrozumieć skalę:

• 1970 – Edgar F. Codd publikuje „A Relational Model of Data for Large Shared Data Banks”.
• lata 70. – IBM tworzy SEQUEL, później przemianowany na SQL.
• 1986–1987 – ANSI i ISO standaryzują język (SQL-86). Od tego momentu SQL nie należy do jednej firmy.

Dodatkowo nie jest to język niszowy. W ankiecie Stack Overflow Developer Survey 2023 SQL-a używało 51,52% zawodowych deweloperów (48,66% wszystkich respondentów).

Cztery mutacje

Najciekawsze jest to, co działo się z SQL-em, gdy pojawiała się technologia, która miała go „zabić”.

Na prelekcji podsumowałem to zdaniem, które lubię najbardziej z całego decku: „Każda era nie zastąpiła poprzedniej – rozszerzyła ją.” Relacyjne bazy nadal obsługują transakcje, hurtownie analitykę, lakehouse data science, a wektory AI. Ewolucja idzie przez specjalizację, a SQL zostaje wspólnym językiem na górze.

Dobrze to widać na przykładzie wektorów. Na slajdzie „Giganci nie czekali” pokazywałem, że PostgreSQL dostał rozszerzenie pgvector, a SQL Server 2025 natywny typ VECTOR. Zamiast przenosić dane do osobnej bazy wektorowej, możemy dodać kolumnę z embeddingami obok istniejących tabel.

Poprawka do mojego własnego slajdu: funkcja do generowania embeddingów w SQL Server 2025 nazywa się AI_GENERATE_EMBEDDINGS, a nie GENERATE_EMBEDDING. W skryptach demo była poprawna nazwa, na slajdzie nie.

Jak ta mutacja wygląda na Databricks

W Databricks SQL wyszukiwanie semantyczne jest po prostu kolejną funkcją w klauzuli FROM. Nie musimy sami liczyć wektora pytania, bo robi to za nas indeks z managed embeddings.

✓ Działa na Free Edition (wymaga endpointu i indeksu AI Search; na Free Edition jest limit jednego endpointu)

SELECT *
FROM vector_search(
  index => '<twoj_katalog>.<schemat>.<indeks>',
  query_text => 'jak prawidłowo parzyć kawę',
  num_results => 3
);

Warto tutaj dodać, że tego fragmentu nie uruchomiłem na labie 29.09.2026. Notebook ma go za przełącznikiem RUN_VECTOR_SEARCH, a na workspace'ie nie było jeszcze endpointu ani indeksu AI Search, więc komórka została pominięta. Składnię traktujcie jako szkic do sprawdzenia w dokumentacji.

To nadal jest SELECT. Zmieniło się to, co dzieje się pod spodem: zamiast porównywać litery, porównujemy znaczenia. Czym dokładnie różni się LIKE, full-text i wektory, opisuję w tekście „Lupa, książka i kumpel”.

AI bez danych to puste pudełko

Druga teza z prelekcji jest dla mnie ważniejsza niż pierwsza: „AI bez danych to puste pudełko.”

Najlepszy model językowy nie wie, jakie mamy produkty, kim są nasi klienci i co wydarzyło się wczoraj w systemie sprzedaży. Może tylko zgadywać. Z drugiej strony mamy petabajty danych, idealnie ułożonych w tabelach, ale klasyczne zapytanie wymaga znajomości struktury, a full-text search szuka słów, nie znaczeń. Pytania „co nasi klienci myślą o produkcie X?” nie zadamy w samym WHERE.

Dlatego nie widzę tu konkurencji. RAG, agenci i Genie potrzebują danych, które ktoś wcześniej zamodelował, oczyścił i opisał. Przy przygotowaniu warsztatu z agentów AI rok później sporo problemów nie leżało w modelu, tylko właśnie w danych: w zdublowanych wierszach klientów, w niejasnej definicji miary, w uprawnieniach, które znikały po odtworzeniu funkcji. To jest dokładnie ten obszar, w którym ludzie od SQL-a czują się najpewniej.

Od lat 90. co kilka lat ktoś wieszczy śmierć SQL-a. A dziś mamy Spark SQL, a z poziomu SQL-a wołamy nawet modele AI.

Co z tego wynika w praktyce

Kilka rzeczy, które sam robię i polecam osobom z zespołów danych:

1. Nie porzucajmy SQL-a na rzecz „samego AI”. Jeśli agent albo Genie generuje zapytanie, ktoś musi umieć je przeczytać i ocenić, czy liczy to, co trzeba.
2. Uczmy się nowych funkcji w starym języku. ai_query, funkcje AI i wyszukiwanie wektorowe na Databricks wołamy z SQL. Próg wejścia jest niski, bo składnia jest znana.
3. Dbajmy o semantykę danych. Komentarze na tabelach i kolumnach, definicje miar, jasne nazwy. To z nich korzystają Genie i agenci.
4. Wybierajmy metodę do problemu. LIKE i regex nadal są najlepsze, gdy znamy wzorzec (kod produktu, e-mail). Wektory mają sens, gdy szukamy intencji.

Czego ta teza nie mówi

„SQL nie umiera” nie znaczy, że wszystko należy robić w SQL. Model ML trenujemy w Pythonie, agenta składamy w kodzie, a nie w procedurze składowanej. Nie znaczy też, że SQL sam z siebie rozumie znaczenie. Rozumie je model embeddingów, a SQL daje do niego wygodny interfejs. I wreszcie: to, że SQL przetrwał dotąd, nie jest gwarancją na zawsze. To zależy :) Na razie jednak każda fala nowości kończyła się tym samym: nowym typem danych i nowymi funkcjami w znanym języku.

Zobacz, jak to działa

Krótkie nagranie z labu pokazuje, jak notebook przechodzi po kolei przez przygotowanie tabeli, zapytanie SELECT i pominięty krok z vector_search().

Pełny notebook jest w folderze code/ (sql_mutuje.py).

Podsumowanie

Na zamknięcie prelekcji użyłem zdania, które dobrze streszcza całą serię:

„Struktura bez semantyki to martwe dane. Semantyka bez struktury to chaos.”

• SQL przetrwał, bo oddziela „co” od „jak”, więc pod spodem można wymienić silnik.
• Każda era rozszerzyła poprzednią: JSON, Big Data, a teraz wektory i AI.
• AI potrzebuje danych, a dane potrzebują ludzi, którzy je rozumieją.

Dalej: „Lupa, książka i kumpel: LIKE, full-text i wektory po ludzku”.

Stan na: 29.09.2026