Baza danych to zorganizowany zbiór danych, który pozwala je przechowywać, wyszukiwać, modyfikować i usuwać w efektywny sposób. Każda strona internetowa, aplikacja mobilna, sklep e-commerce, system bankowy i serwis społecznościowy opiera się na bazie danych. WordPress używa MySQL, Google używa Bigtable, Facebook używa MySQL + Cassandra + TAO, Netflix używa Cassandra + DynamoDB.
Ale „baza danych” to nie jeden typ — jest ich kilka, każdy z innymi cechami, zaletami i zastosowaniami. W tym poradniku wyjaśniam 5 głównych rodzajów baz danych, czym się różnią, kiedy który wybrać i podaję konkretne przykłady technologii w każdej kategorii.
Podział baz danych — mapa
| Rodzaj | Model danych | Przykłady | Najlepsze do |
|---|---|---|---|
| Relacyjne (SQL) | Tabele z wierszami i kolumnami | MySQL, PostgreSQL, MariaDB, SQLite, Oracle, MS SQL | Dane strukturalne, transakcje, CMS, e-commerce |
| Dokumentowe | Dokumenty JSON/BSON | MongoDB, CouchDB, Firebase Firestore | Elastyczne schematy, API, startupy, prototypy |
| Klucz-wartość | Pary klucz → wartość | Redis, Memcached, DynamoDB, Riak | Cache, sesje, kolejki, bardzo szybkie odczyty |
| Grafowe | Węzły + krawędzie (relacje) | Neo4j, ArangoDB, Amazon Neptune | Sieci społeczne, rekomendacje, grafy wiedzy |
| Kolumnowe | Kolumny (zamiast wierszy) | Apache Cassandra, HBase, ClickHouse, ScyllaDB | Big Data, analityka, logi, IoT, time-series |
1. Bazy relacyjne (SQL) — fundament internetu
Relacyjne bazy danych przechowują dane w tabelach — jak arkusze kalkulacyjne. Każda tabela ma kolumny (pola: ID, imię, email, data) i wiersze (rekordy: jeden wiersz = jeden użytkownik/produkt/zamówienie). Tabele są powiązane ze sobą relacjami (klucze obce) — np. tabela „Zamówienia” wskazuje na „Użytkowników” i „Produkty”.
Do komunikacji z bazą używasz języka SQL (Structured Query Language):
SELECT * FROM users WHERE email = 'jan@example.com';
INSERT INTO orders (user_id, product_id, amount) VALUES (1, 42, 99.99);
UPDATE products SET price = 149.99 WHERE id = 42;
DELETE FROM sessions WHERE last_active < '2026-01-01';Cechy relacyjnych baz danych
- Schemat — struktura jest zdefiniowana z góry (kolumny, typy danych). Nie możesz wrzucić „czegokolwiek” — dane muszą pasować do schematu.
- ACID — transakcje gwarantują: Atomowość (wszystko albo nic), Spójność (dane zawsze poprawne), Izolacja (transakcje nie przeszkadzają sobie), Trwałość (dane nie znikną po awarii). Kluczowe dla: bankowości, e-commerce, systemów rezerwacji.
- Relacje — JOIN-y łączą dane z wielu tabel w jednym zapytaniu. Np. „pokaż zamówienia użytkownika Jan Kowalski z produktami i cenami”.
- Dojrzałość — SQL istnieje od lat 70. Ogromna dokumentacja, narzędzia, eksperci, społeczność.
Przykłady technologii
- MySQL / MariaDB — najpopularniejsze na świecie. WordPress, Drupal, Joomla, większość CMS-ów. Darmowe, open source.
- PostgreSQL — „zaawansowany MySQL”. Lepsze typy danych (JSON, array, full-text search), rozszerzenia (PostGIS dla geo). Popularny w startupach i projektach Python/Django.
- SQLite — plikowa baza (nie wymaga serwera). Wbudowana w każdy telefon (Android, iOS), każdą przeglądarkę, Python. Idealna do małych aplikacji i prototypów.
- Oracle / MS SQL Server — enterprise, płatne, korporacyjne. Banki, telekomy, rząd.
Kiedy wybrać SQL
Dane mają klarowną strukturę (użytkownicy, produkty, zamówienia), potrzebujesz transakcji ACID (płatności, rezerwacje), dane są powiązane relacjami (JOIN-y), potrzebujesz raportowania SQL. To domyślny wybór — 80% aplikacji webowych używa relacyjnej bazy.
2. Bazy dokumentowe (Document DB)
Bazy dokumentowe przechowują dane jako dokumenty — najczęściej w formacie JSON (lub BSON w MongoDB). Każdy dokument to samodzielny „obiekt” z polami i wartościami:
{
"_id": "user_001",
"name": "Jan Kowalski",
"email": "jan@example.com",
"address": {
"city": "Warszawa",
"zip": "00-001"
},
"orders": [
{ "product": "Laptop", "price": 3999 },
{ "product": "Mysz", "price": 99 }
]
}Czym się różnią od SQL
- Brak schematu (schema-less) — każdy dokument może mieć inne pola. Jeden użytkownik ma „address”, inny nie. Nie musisz definiować kolumn z góry.
- Zagnieżdżone dane — adres i zamówienia są wewnątrz dokumentu użytkownika (nie w osobnej tabeli). Mniej JOIN-ów = szybciej.
- Skalowanie horyzontalne — łatwiej dodać kolejny serwer (sharding), bo dokumenty są niezależne.
Przykłady technologii
- MongoDB — najpopularniejsza dokumentowa baza. Node.js, Python, Java. Darmowa (Community) + płatna (Atlas — chmura).
- Firebase Firestore — baza od Google, zintegrowana z ekosystemem Firebase. Popularna w aplikacjach mobilnych.
- CouchDB — synchronizacja offline, replikacja. Niszowa, ale ciekawa.
Kiedy wybrać dokumentową
Schemat danych zmienia się często (startup, prototyp), dane są zagnieżdżone (JSON z obiektami w obiektach), potrzebujesz skalowania horyzontalnego, budujesz API REST/GraphQL (dane naturalnie mapują się na JSON).
3. Bazy klucz-wartość (Key-Value)
Najprostszy model: klucz (unikatowa nazwa) → wartość (dowolne dane). Jak słownik/mapa/hashmap w programowaniu. Ekstremalnie szybkie, bo brak zapytań SQL, JOIN-ów, indeksów — tylko „daj mi wartość pod kluczem X”.
SET user:123:name "Jan Kowalski"
GET user:123:name → "Jan Kowalski"
SET session:abc123 '{"user_id": 123, "cart": [42, 55]}'
GET session:abc123 → '{"user_id": 123, "cart": [42, 55]}'Przykłady technologii
- Redis — in-memory, ekstremalnie szybki (<1 ms). Cache, sesje, kolejki, leaderboardy. Najpopularniejsza klucz-wartość baza.
- Memcached — prostszy Redis, tylko cache.
- Amazon DynamoDB — chmurowa, managed, skalowalna. AWS.
Kiedy wybrać klucz-wartość
Potrzebujesz ekstremalnej szybkości odczytu/zapisu, przechowujesz proste dane (sesje, cache, tokeny, countery), nie potrzebujesz złożonych zapytań (filtrowanie, JOIN-y, aggregacje). Redis jako cache + MySQL jako główna baza to standardowa architektura WordPress i wielu aplikacji.
4. Bazy grafowe (Graph DB)
Bazy grafowe przechowują dane jako węzły (entities) i krawędzie (relacje między nimi). Idealne do danych, gdzie relacje są ważniejsze niż same dane.
Przykład: sieć społecznościowa. Węzły: osoby. Krawędzie: „zna”, „obserwuje”, „lubi”, „pracuje w”. Zapytanie „kto zna kogoś, kto zna Marka?” w SQL to koszmarny multi-JOIN. W grafowej bazie to proste traversal.
Przykłady technologii
- Neo4j — najpopularniejsza grafowa baza. Język zapytań: Cypher.
- Amazon Neptune — managed, chmurowa (AWS).
- ArangoDB — multi-model (dokumentowa + grafowa + klucz-wartość).
Kiedy wybrać grafową
Dane mają złożone relacje (sieć społeczna, system rekomendacji, fraud detection, knowledge graph), potrzebujesz szybkich zapytań „kto jest powiązany z kim przez 3 stopnie separacji”. Niszowe, ale potężne w swoim zastosowaniu.
5. Bazy kolumnowe (Column-Family / Wide-Column)
Bazy kolumnowe przechowują dane per kolumna, nie per wiersz. W relacyjnej bazie: jeden wiersz = jeden rekord (Jan, Kowalski, 30, Warszawa). W kolumnowej: kolumna „imię” = [Jan, Anna, Piotr, …], kolumna „wiek” = [30, 25, 40, …].
Zaleta: zapytania analityczne (SUM, AVG, COUNT) na jednej kolumnie są wielokrotnie szybsze, bo baza czyta tylko jedną kolumnę zamiast wszystkich wierszy.
Przykłady technologii
- Apache Cassandra — rozproszona, skalowalna. Netflix, Discord, Apple.
- Apache HBase — na Hadoop. Big Data.
- ClickHouse — analityka, logi, dashboardy. Ekstremalnie szybkie agregacje.
- ScyllaDB — kompatybilna z Cassandra, szybsza (C++ vs Java).
Kiedy wybrać kolumnową
Big Data (miliardy wierszy), analityka (dashboardy, raporty, agregacje), logi i time-series (IoT, monitoring, metryki), rozproszony system (wiele datacenter, replikacja globalna). Nie do typowych aplikacji webowych — to narzędzie dla inżynierów danych.
SQL vs NoSQL — porównanie
„NoSQL” to zbiorcza nazwa na wszystko, co nie jest relacyjne (dokumentowe, klucz-wartość, grafowe, kolumnowe):
| Cecha | SQL (relacyjne) | NoSQL |
|---|---|---|
| Schemat | Sztywny (zdefiniowany z góry) | Elastyczny (schema-less) |
| Język zapytań | SQL (ustandaryzowany) | Różny per technologia |
| Transakcje ACID | Tak (pełne) | Zależy (MongoDB: tak, Redis: ograniczone) |
| Skalowanie | Głównie wertykalne (większy serwer) | Głównie horyzontalne (więcej serwerów) |
| JOIN-y | Tak (potężne) | Ograniczone lub brak |
| Najlepsze do | Dane strukturalne, transakcje | Elastyczne dane, cache, skala |
| Przykłady | MySQL, PostgreSQL, SQLite | MongoDB, Redis, Cassandra, Neo4j |
Zasada: nie wybieraj „SQL vs NoSQL” — wybieraj narzędzie do problemu. WordPress + MySQL (SQL) z Redis (klucz-wartość) jako cache to dwa różne typy baz danych pracujące razem. Netflix używa Cassandra (kolumnowa) do danych o oglądaniu i MySQL (relacyjna) do rozliczeń. Mieszanie typów to norma.
Najczęściej zadawane pytania
Jakiej bazy danych używa WordPress?
MySQL (lub MariaDB — fork MySQL). WordPress przechowuje w MySQL: wpisy, strony, komentarze, użytkowników, ustawienia, menu, metadane. Dla cache WordPress może używać Redis (klucz-wartość). Ale główna baza to zawsze MySQL.
MySQL vs PostgreSQL — co wybrać?
MySQL: prostszy, szybszy w prostych odczytach, dominuje w CMS-ach (WordPress, Drupal). PostgreSQL: bardziej zaawansowany (typy JSON, full-text search, GIS, procedury), lepszy do złożonych aplikacji. Dla WordPressa: MySQL. Dla nowej aplikacji w Django/Rails/Next.js: PostgreSQL.
Czy muszę znać SQL?
Jeśli pracujesz z danymi, administrujesz stronami lub budujesz aplikacje: tak, podstawy SQL są niezbędne. SELECT, INSERT, UPDATE, DELETE, JOIN, WHERE, GROUP BY — to fundament. Nawet jeśli używasz ORM-a (Eloquent, SQLAlchemy, Prisma), SQL pod spodem i tak się przydaje do debugowania i optymalizacji.
Co to jest ORM?
ORM (Object-Relational Mapping) to warstwa, która pozwala pisać kod w języku programowania (Python, PHP, JavaScript) zamiast SQL. Np. w Django: User.objects.filter(email='jan@example.com') zamiast SELECT * FROM users WHERE email='jan@example.com'. ORM tłumaczy to na SQL za kulisami.
Podsumowanie
5 rodzajów baz danych, 5 zastosowań: relacyjne (SQL) do danych strukturalnych i transakcji (WordPress, e-commerce, banki), dokumentowe do elastycznych danych JSON (API, startupy, MongoDB), klucz-wartość do cache i sesji (Redis), grafowe do relacji między danymi (sieci społeczne, rekomendacje), kolumnowe do Big Data i analityki (logi, IoT, ClickHouse). Domyślny wybór: MySQL lub PostgreSQL + Redis jako cache. Reszta — gdy masz konkretne potrzeby, których SQL nie pokrywa.
