SQL umarł. Niech żyje SQL!
Jestem w Enterprise IT od 30 lat. Wystarczająco długo, by zobaczyć wiele mód, które przyszły i odeszły, oraz całe cmentarzysko niespełnionych obietnic składanych przez handlowców i konsultantów, którzy obiecywali firmom prawdziwy, przełomowy wpływ innowacji technologicznych.
Oto kilka przykładów rzeczy, które sprzedawano nam jak świętego Graala, a które okazały się efemerydami albo po krótkiej chwili sławy trafiły do nisz.
Są jednak również przypadki odwrotne. Technologie, które dekady temu uznano za martwe, dotrwały do ery AI i mają się dziś świetnie.
Większość długoterminowych prognoz dotyczących adopcji technologii po prostu się nie sprawdza.
Wpływa na to wiele czynników, ale jeden wyróżnia się szczególnie. Mamy notoryczną tendencję do niedoceniania inercji w adopcji technologii, szczególnie w Enterprise IT.
Być może częściowo wynika to z ludzkiej natury, ale przede wszystkim z doświadczeń specjalistów pracujących w środowiskach enterprise. Tak, IT musi dostarczać biznesowi innowacje o realnym wpływie, by poprawiać konkurencyjność i wspierać wzrost. Ale podstawową funkcją liderów IT jest zarządzanie ryzykiem i optymalizacja kosztów w odpowiedniej równowadze, tak by wszystko działało bez przerw. Dotyczy to zarówno ludzi, jak i technologii, i wykracza daleko poza samą dostępność systemów oraz cyberbezpieczeństwo.
Jak podejmuje się decyzje w Enterprise IT
Żeby podać prosty przykład: jako CTO, wybierając język programowania do nowego projektu, muszę patrzeć znacznie szerzej niż tylko na możliwości samego języka. Inne czynniki są w moim procesie decyzyjnym jeszcze ważniejsze. Muszę spojrzeć do wnętrza firmy i na szerszy rynek, aby zrozumieć, jak popularny jest dany język. Czy łatwo będzie zatrudnić programistów dla tego języka?
Na przykład gdybym miał wybierać między JavaScriptem a Ruby dla nowego projektu w 2025 roku, szybko sprawdziłbym, że według badania StackOverflow ponad 66% programistów zna JavaScript, a tylko 6,4% zna Ruby (potencjalną alternatywę po stronie serwera). W takiej sytuacji, nawet jeśli Ruby byłby lepszą opcją, prawdopodobnie wybrałbym JavaScript. Nie chodzi tylko o to, że rekrutacja byłaby potencjalnie łatwiejsza, lecz także o to, że większa społeczność oznacza bardziej kompletny ekosystem: tooling, wsparcie, dostępność firm świadczących usługi profesjonalne itd. Podobnie przy wyborze narzędzia do recruitment marketingu firmy często stawiają na platformy z dużą bazą użytkowników i silnym wsparciem ekosystemu,
co zapewnia długoterminową stabilność i łatwiejszą integrację.
Następnie muszę spojrzeć na trendy długoterminowe. Jak długo dany język istnieje? Czy adopcja nadal rośnie, ustabilizowała się, czy już spada? Czy język będzie się dalej rozwijał, by wchłaniać nowe trendy i innowacje? Czy za 5 lub 10 lat nadal będzie dostępne wsparcie?
I właśnie tutaj naprawdę zaczyna się nasza historia o SQL i jego dziejach.
Czym jest SQL?
SQL to szeroko stosowany, standaryzowany, w przeważającej mierze deklaratywny język programowania z elementami proceduralnymi, którego celem jest definiowanie struktur danych, manipulowanie nimi, odpytywanie ich i kontrolowanie danych. Opiera się na algebrze relacyjnej i znacząco ulepszył wcześniejsze techniki zapytań i manipulacji danymi, takie jak VSAM. Instrukcja składa się z klauzul, wyrażeń, predykatów, zapytań i rekurencyjnych podzapytań.
Zawsze istniały rozszerzenia i dialekty specyficzne dla dostawców, ale rdzeń języka jest zgodny ze standardem we wszystkich głównych implementacjach. Niezgodności dotyczą typów danych i bardziej zaawansowanych konstrukcji.
SQL nie jest doskonały. Nie zawsze konsekwentnie trzyma się swoich eleganckich podstaw matematycznych, nie jest optymalny dla danych hierarchicznych i grafowych, nigdy też dobrze nie wpisał się w paradygmat obiektowy. Ogólnie nie integruje się płynnie ani z językami obiektowymi, ani proceduralnymi (tu pojawia się Object-Relational Mapping, czyli ORM). Bardziej złożone instrukcje mogą być niezręczne w pisaniu i czytaniu, a pisanie dużej, złożonej logiki w całości w SQL lub PL/SQL nie jest wydajne.
Dlatego z czasem zaproponowano wiele alternatyw, a kilka z nich osiągnęło całkiem spory sukces, np. języki zapytań dla grafów i noSQL dla magazynów klucz-wartość oraz danych dokumentowych.
Jednak większość udanych alternatyw ostatecznie ustabilizowała się w swoich niszach, a w ostatnich latach widać wręcz odwrót od części z nich na rzecz SQL. Z drugiej strony niektóre z tych koncepcji, takie jak JSON czy grafy, zostały już zaadaptowane do nowszych wersji SQL, co zmniejsza potrzebę sięgania po alternatywy.
SQL jest stary, ale to wyraźny zwycięzca tego maratonu.
Początki SQL
Początki SQL sięgają wczesnych lat 70. XX wieku. W 1970 roku Edgar F. Codd opublikował A Relational Model of Data for Large Shared Data Banks, wprowadzając relacyjny model baz danych.
Były to narodziny RDBMS, całkowicie nowej wówczas kategorii systemów IT, która dziś, 55 lat później, nadal znajduje się w światowej top 3 (obok infrastruktury IT i systemów ERP). Adopcję RDBMS napędzał wzrost ERP, a adopcja SQL szła z tym ręka w rękę. Jak bliźnięta, jedno nie może istnieć bez drugiego.
W latach 1974-1977 powstały dwa ważne prototypy relacyjnych systemów baz danych. Były to Ingres, rozwijany na UC Berkeley (UCB), oraz System R stworzony w IBM San Jose. Ingres używał języka zapytań QUEL i doprowadził do powstania takich systemów jak Ingres Corp., MS SQL Server, Sybase, PostgreSQL, Wang’s PACE i Britton-Lee. Z kolei System R używał języka zapytań SEQUEL i przyczynił się do rozwoju SQL/DS, DB2, Allbase, Oracle i Non-Stop SQL.
To właśnie w tej dekadzie termin Relational Database Management System, czyli RDBMS, stał się powszechnie rozpoznawalny.
Standaryzacja i adopcja SQL
Po niemal 10 latach badań i rozwoju SQL, lata 80. stały się dekadą komercjalizacji i standaryzacji RDBMS. W tym czasie wprowadzono kilka komercyjnych systemów baz danych. Należały do nich Oracle V2 (1979), Sybase SQL Server (1984), IBM DB2 for Mainframes (1983, następca System R), IBM Informix (1985), Microsoft SQL Server 1.0 (1987) oraz SAP DB (1988).
Ważnym krokiem było przyjęcie SQL jako standardowego języka baz danych przez ANSI i ISO odpowiednio w 1986 i 1987 roku. Standard ten przechodził z czasem wiele iteracji, a jego najnowsza rewizja pochodzi z 2023 roku.
Powody, dla których dostawcy wsparli standaryzację, obejmowały oczekiwanie szybszego ogólnego wzrostu dzięki standardowi na rozwijającym się rynku; obawę przed przegraniem z konkurencją w przypadku braku wsparcia standardu; możliwość wpływania na sam standard; oraz korzyści ekosystemowe.
Wczesny sukces SQL nie wziął się znikąd. Popyt był wyraźny.
Jednak masowy wzrost zaczął się tak naprawdę dopiero na początku lat 90. Został on wywołany przez spadające ceny sprzętu, wzrost architektur klient-serwer z UNIX-em i PC oraz adopcję ERP. To była też dekada pojawienia się open source’owych relacyjnych baz danych: MySQL (1995), PostgreSQL (1996) i MariaDB (1999).
Genealogia relacyjnych baz danych jest dość złożona – szczegóły można zobaczyć tutaj.
Obecny krajobraz i perspektywy
W skrócie: SQL zostaje. I nie tylko zostaje. Jest bardziej żywy niż kiedykolwiek i nadal rośnie. Ten dinozaur nie tylko przetrwał wszystkich nowoczesnych konkurentów, ale też przebił ich pod względem popularności.
To doskonały przykład na to, że w długim okresie koncepcje technology adoption lifecycle i Gartner Hype Cycle nie zawsze mają zastosowanie. SQL wszedł już w „późny etap” według każdej definicji, a mimo to rośnie szybciej niż kiedykolwiek wcześniej. Przykładem może być Gartner Hype Cycle z 2018 roku, gdzie SQL nie był już nawet osobną kategorią (i nadal nie jest nią w 2025 roku).
W ciągu ostatnich pięciu lat bazy danych SQL nie tylko przetrwały, ale wręcz rozkwitły. W Stack Overflow Developer Survey 2020 MySQL i PostgreSQL już znajdowały się wśród najczęściej używanych baz danych na świecie. W 2025 roku ich przewaga tylko się zwiększyła. MySQL, PostgreSQL, Microsoft SQL Server i SQLite tworzą dziś top 4 baz danych używanych przez profesjonalnych programistów, daleko przed jakąkolwiek alternatywą noSQL. Mimo wieloletnich przewidywań, że „SQL jest martwy”, dane pokazują coś odwrotnego: SQL pozostaje kręgosłupem nowoczesnego oprogramowania i systemów opartych na danych.
Dlaczego SQL znów żyje?
Oto moje cztery hipotezy, dlaczego SQL wraca dziś z taką siłą. Śmiało się ze mną spierajcie – bardzo jestem ciekaw waszych opinii.
Fundament
SQL był jednym z pierwszych języków deklaratywnych (w przeciwieństwie do bardziej typowych wówczas języków proceduralnych). Język deklaratywny pozwala opisać, czego chcemy, zamiast tego, jak to zrobić. To bardzo atrakcyjne dla użytkowników, którzy nie są dobrze zaznajomieni z innymi językami programowania. SQL jest bardzo łatwy do nauczenia i stosowania (przynajmniej w podstawowych przypadkach użycia), a jednocześnie zapewnia ogromny poziom elastyczności, dzięki czemu nadaje się do bardzo szerokiego zakresu wzorców dostępu do danych, od zapytań ad hoc po transakcyjny dostęp i manipulację danymi.
Dojrzałość
Oczywiście technologia, która była rozwijana i dojrzewała przez tak długi czas, może być uznana za bardzo stabilną i kompletną. Żaden decydent nie podejmuje technologicznego ryzyka, wybierając SQL.
Adopcja
Wspomnieliśmy o tym już we wstępie. Poziom adopcji SQL rósł przez długi czas, czasem wolniej, czasem szybciej, ale dziś jest on zdecydowanie dominującym graczem jako język dostępu do danych. Sama ta pozycja dodatkowo zabezpiecza jego przyszły wzrost.
Jeśli zrobimy krótki wypad do teorii przewagi konkurencyjnej w biznesie, wiemy, że na rynkach opartych na platformach dwustronnych liderzy mają ogromną przewagę konkurencyjną. Relacyjne bazy danych oparte na SQL tworzą taką właśnie platformę dwustronną w szerokim sensie:
- Społeczność (lub wiele społeczności w przypadku SQL, bo skupiają się one wokół konkretnych systemów bazodanowych) – obejmuje użytkowników SQL, programistów i innych profesjonalistów
- Branża – obejmuje dostawców systemów, organizacje świadczące usługi profesjonalne, dostawców usług chmurowych i inne podmioty.
To właśnie tutaj wchodzą w grę silne efekty sieciowe. Większa społeczność będzie napędzać rozwój ekosystemu i możliwości systemów, ponieważ branża będzie chciała skapitalizować wielkość rynku. Jednocześnie społeczność będzie rosła sama z siebie, ponieważ wybór technologii przez użytkowników lub organizacje, w których pracują, będzie również napędzany przez wielkość społeczności, aby zarządzać ryzykiem i zapewnić dostęp do talentów.
Efekt ten jest bardzo silny i może nawet prowadzić do tego, że platformy „wchłaniają” przypadki użycia, do których nie zostały zbudowane, jak np. rozszerzenia grafowe i wektorowe dla relacyjnych baz danych.
Ewolucja
Podobnie jak w ewolucji biologicznej, nie jesteśmy w stanie przewidzieć zewnętrznych wydarzeń w ewolucji technologii. Możemy się do nich tylko dostosowywać, kiedy już nastąpią. To nie najsilniejszy, najszybszy ani największy gatunek ma najlepsze szanse przetrwania w długim okresie. Najlepiej radzi sobie ten, który potrafi najlepiej dostosować się do zmian. SQL roku 2025 nie jest już SQL-em z 1970 roku.
SQL po drodze wchłonął istotne zmiany, w tym big data i systemy rozproszone (sharding i partycjonowanie, rozproszone bazy SQL, kolumnowe przechowywanie danych i analitykę), płynną integrację z nowoczesnymi językami programowania i AI, wsparcie dla danych częściowo ustrukturyzowanych i nieustrukturyzowanych (json, typy tablicowe, xml), dostosowanie do analityki czasu rzeczywistego, wsparcie dla zaawansowanej analityki i ML (np. BigQuery ML, rozszerzenia PostgreSQL), integrację z pipeline’ami AI, przetwarzanie in-memory, wektoryzowane wykonywanie zapytań i ML przyspieszane przez GPU.
Co dalej z SQL?
SQL udowodnił, że potrafi ewoluować szybciej niż przewidywania o jego upadku. Gdy AI, wyszukiwanie wektorowe i analityka czasu rzeczywistego zmieniają sposób budowania aplikacji, SQL nadal się dostosowuje zamiast znikać. Kolejna fala nie zastąpi SQL. Ona go rozszerzy. SQL jest bazą danych pierwszego wyboru dla AI. Zobaczymy głębszą integrację z przetwarzaniem danych napędzanym przez AI, rozszerzenia natywne dla wektorów oraz cloud-native scaling, który sprawi, że bazy danych będą bardziej dynamiczne niż kiedykolwiek.
Dla tych z nas, którzy obserwowali dekady kolejnych hype’ów, przyszłość SQL wydaje się jednocześnie znajoma i nowa. To wciąż język danych – ale teraz mówi także językiem inteligencji. Chętnie poznam wasze opinie o moich hipotezach i o przyszłości SQL.
Osobiście uważam, że SQL wciąż jest przyszłością i właśnie dlatego budujemy Velę. Vela to nowoczesna platforma Backend-as-a-Service zbudowana na Postgresie. Dzięki temu możemy pokazać, jak Postgres utrzymuje SQL jako istotną technologię dla dzisiejszych obciążeń cloud i AI.