1 godzina temu
Najważniejsza zmiana na rynku baz danych nie polega na tym, iż SQL przegrał z NoSQL, ale na tym, iż jedna baza coraz rzadziej wystarcza do obsługi wszystkich rodzajów danych, które produkuje współczesna firma.
Relacyjne bazy pozostają rdzeniem systemów transakcyjnych. Finanse, ERP, CRM, rozliczenia czy zamówienia przez cały czas potrzebują integralności danych, transakcji ACID i przewidywalnych relacji między rekordami. PostgreSQL w badaniu Stack Overflow Developer Survey 2025 trzeci rok z rzędu był jednocześnie najbardziej „desired” i „admired” technologią w kategorii baz danych. Relacyjny model nie znika. Przeciwnie, utrzymuje bardzo silną pozycję.
Zmienia się natomiast to, co dzieje się wokół niego.
AWS w Well-Architected Framework wskazuje trzymanie się jednej technologii bazodanowej tylko dlatego, iż organizacja ma w niej kompetencje, jako architektoniczny antywzorzec. Powód jest prosty: transakcje finansowe, katalog zawierający miliony zmiennych produktów, telemetria urządzeń i wyszukiwanie semantyczne dla modelu AI mają zupełnie inne profile obciążenia. Próba obsłużenia ich identycznym silnikiem często przenosi koszt z licencji na infrastrukturę, development i utrzymanie.
AI zmieniło reguły szybciej niż NoSQL
Najbardziej widoczną zmianę przyniosły bazy wektorowe. Modele generatywne potrzebują dostępu do informacji nie tylko po identycznym słowie czy identyfikatorze, ale według podobieństwa znaczeniowego. Embedding dokumentu, zdjęcia czy produktu staje się kolejnym rodzajem danych przechowywanych obok klasycznych rekordów.
Jeszcze kilka lat temu sugerowało to powstanie osobnej warstwy infrastruktury. Dzisiaj rynek zaczyna iść w przeciwnym kierunku.
Pgvector umożliwia wykonywanie wyszukiwania wektorowego bez opuszczania PostgreSQL. Obsługuje m.in. indeksy HNSW i IVFFlat. Ich charakterystyka dobrze pokazuje problem, którego wcześniej klasyczne aplikacje biznesowe rzadziej doświadczały: większa szybkość wyszukiwania może oznaczać pogodzenie się z niższym recall, czyli możliwością pominięcia części prawidłowych wyników. Architektura danych staje się więc również zarządzaniem kompromisem między precyzją, opóźnieniem, pamięcią i kosztem.
Co ważniejsze, funkcje wektorowe przestają być domeną wyłącznie wyspecjalizowanych baz.
Document360 początkowo korzystał z oddzielnej bazy wektorowej dla swojego asystenta AI. Oznaczało to jednak replikację danych, synchronizację oraz konieczność odtwarzania mechanizmów kontroli dostępu. Firma przeniosła wyszukiwanie do MongoDB Atlas Vector Search. Według case study MongoDB czas zwracania wyników spadł do 2–4 ms, bazowa dokładność odpowiedzi wzrosła do 94 proc., a liczba negatywnych ocen użytkowników spadła o 30 proc. To dane dostawcy i dotyczą konkretnego wdrożenia, ale dobrze pokazują ekonomiczny problem: osobny silnik może przyspieszyć jeden element aplikacji, jednocześnie zwiększając koszt całego systemu.
Dane czasowe pokazują ten sam problem
Innej architektury wymagają logi, metryki infrastruktury, IoT czy telemetria przemysłowa. Tutaj dane napływają stale, a ich znaczenie jest nierozerwalnie związane z czasem. Właśnie dlatego powstały wyspecjalizowane bazy time-series.
Doświadczenia Cloudflare pokazują jednak, iż choćby przy ekstremalnej skali wybór najbardziej wydajnego silnika nie zawsze jest oczywisty.
Firma wykorzystuje setki instancji PostgreSQL i ClickHouse zdolny przyjmować dziesiątki milionów rekordów na sekundę. Mimo to dla części analityki Zero Trust wybrano TimescaleDB, rozszerzenie PostgreSQL. Powodem nie był brak wydajności ClickHouse, ale złożoność potrzebnej infrastruktury. W obecnym rozwiązaniu TimescaleDB obsługuje w niektórych procesach około 100 tys. zagregowanych rekordów na sekundę.
To istotne rozróżnienie. Benchmark pokazuje, który silnik wykonuje operację szybciej. Rachunek firmy obejmuje także Kafka, potoki danych, replikację, monitoring, backup, bezpieczeństwo, kompetencje zespołu i czas potrzebny do wdrożenia zmiany.
Specjalizacja zaczyna ustępować konsolidacji
Po dekadzie rozbijania danych na coraz bardziej wyspecjalizowane systemy rynek zaczyna więc ponownie je łączyć.
Google rozwija Spanner jako platformę obsługującą w jednym środowisku dane relacyjne, grafowe, wektorowe, key-value oraz wyszukiwanie pełnotekstowe. W 2025 r. Google rozszerzył m.in. wyszukiwanie wektorowe ANN i integrację funkcji grafowych z RAG.
Podobny ruch widać w PostgreSQL i MongoDB. Granica między „bazą relacyjną”, „dokumentową” i „wektorową” staje się mniej oczywista.
Nie oznacza to powrotu do jednej uniwersalnej bazy. Cloudflare w 2026 r. opisywał dane rozproszone między PostgreSQL, ClickHouse, Kafka, BigQuery i magazynami obiektowymi jako problem sam w sobie. Zbudował więc własną warstwę zapewniającą jeden interfejs SQL nad wieloma źródłami.
To prawdopodobnie ważniejszy kierunek niż kolejny pojedynek SQL z NoSQL. Firmy nie cierpią dziś na brak technologii do przechowywania danych. Mają ich za dużo.
Koszt następnej bazy nie kończy się na serwerze lub abonamencie chmurowym. Dochodzi kolejna kopia danych, polityka dostępu, pipeline, monitoring, kompetencje i punkt awarii. Dlatego architektura po erze jednego standardu nie polega na maksymalizowaniu liczby wyspecjalizowanych silników. Polega na użyciu ich tylko tam, gdzie przewaga technologiczna jest większa niż koszt kolejnej granicy w systemie.
