Rodzaje baz danych — SQL, NoSQL i kiedy faktycznie wybieram każdy z nich

„Typ bazy danych” nie jest marką. Zarówno PostgreSQL, jak i MySQL są relacyjne. MongoDB i Firestore to magazyny dokumentów. Redis to silnik klucz-wartość, który zespoły traktują jako pamięć podręczną, kolejkę, a czasami jako niebezpieczny magazyn główny. Jeśli wybierzesz bazę danych, ponieważ korzystał z niej tutorial, wybierasz modę. Jeśli wybierzesz tę opcję ze względu na sposób kształtowania danych i sposób, w jaki aplikacja odpytuje je, tworzysz architekturę.

To jest mapa, której używam, gdy ktoś pyta „SQL czy NoSQL?” - zwykle złe pierwsze pytanie. Pierwsze pytanie brzmi: czym jest jeden wiersz (lub dokument lub węzeł) w tym produkcie, co musi pozostać spójne i jakie pytania aplikacja będzie zadawać tysiąc razy dziennie?

1. Co właściwie oznacza „typ”.

Trzy osie liczą się bardziej niż kategoria marketingowa. Zrozum je źle, a logo na pudełku Cię nie uratuje.

• Model danych: tabele z relacjami, zagnieżdżone dokumenty, klucze, wykresy, przedziały czasowe lub wektory.
• Model zapytań: łączenia, filtrowanie według pola, uzyskiwanie po kluczu, przechodzenie przez wykres, zakres w czasie lub „co jest bliskie temu osadzeniu?”
• Gwarancje: transakcje ACID, ostateczna spójność, prostota jednego węzła w porównaniu z klastrem, który będziesz debugować o 2 w nocy.

2. Relacyjny (SQL) - domyślny dla pieniędzy i relacji

PostgreSQL, MySQL, SQLite. Wiersze w tabelach, klucze obce, złączenia, migracje, transakcje ACID. To wciąż właściwe miejsce dla większości produktów internetowych: użytkowników, obszarów roboczych, ról, zamówień, faktur, rezerwacji, zapasów. Jeśli wiersz musi istnieć, ponieważ istnieje inny wiersz lub opłata nie może nastąpić dwukrotnie, potrzebujesz silnika relacyjnego, a nie obiektu blob JSON i modlitwy.

PostgreSQL jest moją wartością domyślną w 2026 r.: JSONB, gdy pole jest naprawdę bez schematu, wbudowany pełny tekst do małego wyszukiwania, pgvector, gdy RAG pojawia się później. Możesz znacznie się rozwinąć, zanim „potrzebujesz” drugiej bazy danych. SQLite jest niedoceniany w przypadku aplikacji działających lokalnie, interfejsów CLI i małych produktów. MySQL jest w porządku, jeśli zespół już go uruchamia - nie zaczynam tam od podstaw.

• Wybierz SQL, jeśli liczy się integralność, raportowanie z połączeniami i „kto za co zapłacił w tym obszarze roboczym”.
• Nie wybieraj SQL, ponieważ jest to „korporacyjny”. Wybierz ją, ponieważ domena jest wykresem faktów, które muszą pozostać zgodne.

3. Bazy dokumentów - elastyczne obiekty, drogie relacje

MongoDB, CouchDB, Firestore, DynamoDB w trybie dokumentu. Dokument jest drzewem JSON. Jest to dobre rozwiązanie, gdy jednostką pracy jest jeden obiekt z zagnieżdżonymi bitami, które zawsze ładują się razem: artykuł CMS, produkt z niechlujnym zestawem atrybutów, profil użytkownika, który zawsze pobierasz w całości.

Pułapka: nadal masz użytkowników, obszary robocze i faktury. Wymyślisz na nowo połączenia w aplikacji, utracisz transakcje obejmujące wiele dokumentów (lub zapłacisz za nie) i spędzisz rok na dodawaniu reguł unikalności, które zapewniłby Ci silnik relacyjny już pierwszego dnia. Korzystam z magazynu dokumentów, gdy produkt ma kształt treści, a wzorzec dostępu to „załaduj ten obiekt blob według identyfikatora”. Nie używam go, bo frontend mówi JSON. Postgres JSONB już mówi JSON.

4. Klucz-wartość – Redis i przyjaciele

Redis, Memcached, DynamoDB jako czysty magazyn klucz-wartość. Zdobądź, ustaw, wygasnij. Opcjonalnie listy, zestawy, pub/sub. Nie tu żyje biznes płytowy. Jest to szybka warstwa obok niej.

• Dobrze: sesje, limity szybkości, flagi funkcji, klucze idempotencji, pamięć podręczna kosztownych odczytów, krótkotrwałe blokady.
• Źle: jedyna kopia zamówień, użytkowników lub uprawnień. Jedna polisa dotycząca spłukiwania lub eksmisji i masz koszmar ze wsparciem.

5. Szeroka kolumna - kiedy pisze, nigdy się nie kończy

Cassandra, Skylla, Bigtable. Dzielisz według klucza, dużo piszesz, czytasz według tego klucza i akceptujesz, że nie o to chodzi w SQL ad hoc. Odpowiednie do telemetrii na ogromną skalę, kanałów informacyjnych w stylu skrzynki odbiorczej i obciążeń wymagających dużej liczby zapisów w wielu regionach. Źle w przypadku rezerwacji SaaS z dwunastoma stolikami. Jeśli nie masz jeszcze liczby typu „miliony zapisów na sekundę”, pomiń tę kategorię. Kosztem operacyjnym klastra jest produkt.

6. Wykres - gdy chodzi o połączenie

Neo4j, Amazon Neptune i – w przypadku małych wykresów – SQL z rekursywnymi CTE. Użyj silnika graficznego, gdy produktem jest sieć: rekomendacje, kręgi oszustów, schematy organizacyjne, dziedziczenie uprawnień, „kto jest dwa przeskoki od tego dostawcy”. Nie używaj go, ponieważ narysowałeś ramki i strzałki na tablicy. Prawie każda domena ma relacje. Relacyjne bazy danych już modelują relacje. Silniki grafowe zarabiają na siebie, gdy zapytaniem jest głębokość przejścia, a nie diagram schematu.

7. Szeregi czasowe – metryki, czujniki, zdarzenia w czasie

InfluxDB, TimescaleDB, Prometheus dla operacji, ClickHouse dla zdarzeń o charakterze analitycznym. Jeśli każdy wiersz to „to urządzenie lub metryka w tej sygnaturze czasowej”, ogólny schemat OLTP będzie szkodliwy: zbyt wiele wstawień, skanów zakresów, zasad przechowywania. TimescaleDB jest atrakcyjny, ponieważ pozostaje PostgreSQL — te same kopie zapasowe, ten sam SQL, hipertabele dla gorącej ścieżki. ClickHouse służy do analiz, a nie do transakcji przy kasie. Nie umieszczaj tabeli zamówień w silniku szeregów czasowych, ponieważ istnieje kolumna create_at.

8. Wektor – osadzenia, a nie drugie źródło prawdy

Pinecone, Qdrant, Weaviate i pgvector w Postgresie. Przechowujesz wektory, abyś mógł zapytać „jaki tekst jest bliski temu pytaniu?” To jest RAG, wyszukiwanie semantyczne, wykrywanie duplikatów. Artykuł, cena, użytkownik – te informacje nadal znajdują się w operacyjnej bazie danych. Indeks wektorowy jest indeksem pochodnym, podobnie jak wyszukiwanie. Odbuduj go. Nie pozwól, aby realizacja transakcji lub uprawnienia od tego były zależne.

W 2026 roku najpierw dodam pgvector do Postgres. Dedykowana baza danych wektorów, gdy rozmiar korpusu i liczba pikseli uzasadniają użycie kolejnej ruchomej części – nie dlatego, że w prezentacji napisano „natywny dla sztucznej inteligencji”.

9. Wyszukiwanie nie jest bazą danych

Elasticsearch, OpenSearch, Typesense, Meilisearch. Pełny tekst, tolerancja literówek, aspekty, ranking. Odbuduj ze źródła prawdy. Nigdy nie pozwól, aby realizacja transakcji, zapasy lub uprawnienia zależały wyłącznie od indeksu, który może dryfować po nieudanym ponownym indeksowaniu. Pełny tekst Postgres wystarczy dla wielu małych katalogów. Dodaj wyszukiwarkę, gdy użytkownicy wpisują chaotyczne zapytania i potrzebujesz trafności, a nie wtedy, gdy znudzi Ci się SQL.

10. Jak właściwie wybieram

Uruchamiam filtry w tej kolejności. Stos pojawia się po odpowiedziach, a nie przed tabelą porównawczą.

• Jaka jest jednostka konsystencji? Jeśli przenoszą się pieniądze lub zapasy, SQL z transakcjami. Nie „naprawimy dublety w aplikacji”.
• Jakie jest najczęstsze zapytanie? Według identyfikatora, połączenia, pełnego tekstu, podobieństwa, zakresu czasu lub przeskoku wykresu? Dopasuj silnik do tego kształtu.
• Kto to obsługuje o 2 w nocy? Jeden zarządzany Postgres pokonuje sprytny klaster, którego nikt w zespole nie jest w stanie debugować.
• Czy jeden silnik może pokryć 80%? Postgres plus Redis obejmuje większość produktów internetowych, które faktycznie wysyłam.

Właściwie zacząłbym od domyślnej wersji z 2026 roku

O ile model danych nie zmusi specjalisty od pierwszego dnia, jest to stos, z którym otworzyłbym i nie będę go rozszerzał, dopóki nie pojawi się wymierzone wąskie gardło, a nie post na blogu.

• PostgreSQL jako źródło prawdy. JSONB, w którym pole jest rzeczywiście pozbawione schematu. pgvector, jeśli RAG jest rzeczywistym obiektem, a nie slajdem.
• Redis dla pamięci podręcznej, sesji, limitów szybkości i lekkich kolejek. Nie dla rozkazów.
• Obiektowa pamięć masowa plików. Wyszukiwarka tylko wtedy, gdy LIKE i Postgres FTS nie wystarczą.

Typ to kształt dzieła

SQL vs NoSQL był argumentem z 2010 roku. Przydatnym pytaniem w roku 2026 będzie: który model danych pasuje do danego zadania i w ilu systemach można dobrze działać? Zacznij od relacyjnego źródła prawdy. Dodaj sklep specjalistyczny, gdy kształt zapytania jest naprawdę inny - pamięć podręczna, wyszukiwanie, wektory, szeregi czasowe. Hybryda jest normalna. Pięć baz danych pierwszego dnia MVP to śmierć eksperymentu.