Firebase Firestore — co to jest, dokumenty i kolekcje NoSQL

Czym jest Firebase Firestore

Firebase Firestore — to chmurowa baza NoSQL uruchomiona przez Google w 2019 roku jako następca Realtime Database. Firestore jest zbudowany na infrastrukturze Google Cloud Spanner i Google Cloud Datastore, zapewniając ścisłą spójność danych w ramach jednej transakcji oraz automatyczną replikację wieloregionalną. SDK obsługuje Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform i Unity.

Ewolucja od Realtime Database

Firestore został ogłoszony na Google I/O 2017 jako „Cloud Firestore” — rozwiązanie eliminujące kluczowe ograniczenia Realtime Database: brak obsługi złożonych zapytań, niemożliwość skalowania danych na wielu węzłach i słabą spójność. Według danych Google (2026), Firestore przetwarza ponad 1 bilion zapytań dziennie i jest domyślną bazą danych dla 80% nowych projektów Firebase. Jednak Realtime Database pozostaje aktualna dla scenariuszy z ultra-niskim opóźnieniem (gry, wspólne edytowanie) dzięki prostej strukturze JSON.

Bezpłatne limity Firestore

Firestore jest dostępny w modelu pay-as-you-go z hojnym bezpłatnym limitem na taryfie Spark: 1 GB pamięci, 10 GB ruchu sieciowego miesięcznie, 50 tysięcy operacji odczytu, 20 tysięcy operacji zapisu i 20 tysięcy operacji usunięcia dziennie. Na taryfie Blaze wszystko to jest bezpłatne, a przekroczenia są taryfikowane: $0.06 za 100 tysięcy operacji odczytu, $0.18 za 100 tysięcy operacji zapisu. Według danych Google (2026), 90% projektów nie wychodzi poza bezpłatny limit.

Model danych: kolekcje, dokumenty i pola

Model danych Firestore jest zorganizowany hierarchicznie: korzeń zawiera kolekcje, każda kolekcja zawiera dokumenty, każdy dokument zawiera pola (typy proste, tablice, Map) i zagnieżdżone kolekcje (subcollections). Głębokość zagnieżdżenia kolekcji nie jest ograniczona, ale dokument nie może bezpośrednio zawierać innego dokumentu — tylko przez referencję (Reference type).

Kolekcje i dokumenty

Kolekcja — to kontener dokumentów z automatycznie generowanymi lub zadanymi identyfikatorami. Każdy dokument to obiekt podobny do JSON o rozmiarze do 1 MiB. Pola dokumentu mogą być ciągami znaków, liczbami, wartościami logicznymi, tablicami, Map, znacznikami czasu (Timestamp), punktami geograficznymi (GeoPoint) i referencjami do innych dokumentów (Reference). Rozmiar dokumentu jest ograniczony do 1 MiB, włączając nazwy wszystkich pól.

Zapis wsadowy i transakcje

Firestore obsługuje atomowe transakcje na poziomie bazy danych. Transakcja może odczytywać i zapisywać wiele dokumentów — Commit atomowo stosuje wszystkie zmiany lub żadną. Maksymalnie 500 operacji na jedną transakcję, limit czasu 60 sekund. Zapis wsadowy (batch write) — to nie-transakcyjna atomowa operacja zapisu bez etapu odczytu. Transakcje są krytyczne dla operacji finansowych, rezerwacji miejsc i inwentaryzacji.

Porównanie Firestore i Realtime Database

Wybór między Firestore a Realtime Database zależy od wymagań projektu. Obie bazy danych wchodzą w skład ekosystemu Firebase, zapewniają synchronizację w czasie rzeczywistym i są dostępne na wszystkich platformach, ale zasadniczo różnią się modelem danych, skalowaniem i cenami.

Kluczowe różnice

Realtime Database przechowuje dane w jednym drzewie JSON, co jest wygodne dla prostych struktur, ale utrudnia skalowanie przy zagnieżdżeniu głębszym niż 3 poziomy. Firestore używa modelu kolekcja-dokument z automatycznym shardowaniem, co pozwala skalować się do milionów dokumentów bez pogorszenia wydajności. Według danych Google (2026), Firestore obsługuje do 10 tysięcy równoczesnych połączeń do jednej kolekcji bez utraty prędkości, Realtime Database — do 200 tysięcy połączeń do jednej instancji.

Cennik

Realtime Database jest taryfikowana według objętości przesłanych danych (pobranych bajtów) i liczby równoczesnych połączeń. Firestore — według liczby operacji (odczyt, zapis, usunięcie). Dla aplikacji z częstymi małymi aktualizacjami (czat, powiadomienia) Firestore jest zazwyczaj korzystniejszy — każda operacja zapisu ma stałą cenę niezależnie od rozmiaru danych. Dla aplikacji z rzadkimi odczytami dużych ilości danych Realtime Database może być tańsza.

Zalecenie Google (2026): używaj Firestore jako domyślnej bazy danych dla nowych projektów, a Realtime Database — dla gier i aplikacji, gdzie krytyczne jest minimalne opóźnienie (poniżej 50 ms) i struktura danych jest płaska. Obie bazy mogą działać jednocześnie w jednym projekcie.

Zapytania, indeksy i paginacja w Firestore

Zapytania Firestore są wykonywane na kolekcjach lub grupach kolekcji z filtrowaniem, sortowaniem i limitem. W przeciwieństwie do Realtime Database, gdzie każde zapytanie to przeszukanie całego drzewa JSON z filtrem po stronie klienta, Firestore wykonuje wszystkie zapytania na serwerze, używając wstępnie utworzonych indeksów. Gwarantuje to, że złożoność zapytania zależy tylko od rozmiaru wyniku, a nie od rozmiaru kolekcji.

Rodzaje zapytań

Firestore obsługuje filtrowanie po jednym lub wielu polach (equality, range, in, array-contains, array-contains-any), sortowanie rosnąco i malejąco, limit i kursory do paginacji. Ograniczenia: złożone zapytania z filtrowaniem po różnych polach (where price > 10 AND where category == „books”) wymagają złożonego indeksu; zabronione są zapytania OR (używa się in i array-contains-any) oraz zapytania z nierównością po różnych polach.

data class Product(
    val name: String = "",
    val category: String = "",
    val price: Double = 0.0,
    val inStock: Boolean = false
)

suspend fun FirestoreRepository.queryProducts(): List<Product> {
    return firestore
        .collection("products")
        .whereEqualTo("category", "electronics")
        .whereGreaterThanOrEqualTo("price", 100.0)
        .whereLessThan("price", 500.0)
        .orderBy("price")
        .limit(20)
        .get()
        .await()
        .toObjects(Product::class.java)
}

Indeksy automatyczne i złożone

Firestore automatycznie tworzy indeksy dla pojedynczych pól — zapytania po jednym polu działają bez żadnej konfiguracji. Dla zapytań z dwoma lub więcej polami (filtrowanie + sortowanie) tworzone są indeksy złożone. Przy pierwszym wysłaniu zapytania Firestore zwraca błąd z linkiem do konsoli, gdzie można utworzyć indeks jednym przyciskiem. Maksymalnie 200 indeksów złożonych na bazę danych. Indeksy można eksportować i importować przez firebase CLI.

Integracja Firestore w Android

Podłączenie Firestore do aplikacji Android wykonuje się standardowo przez Firebase BOM. Po dodaniu zależności firebase-firestore-ktx obiekt FirebaseFirestore jest dostępny przez getInstance() — bez dodatkowych kluczy ani tokenów. Firestore używa tego samego projektu Firebase co pozostałe usługi.

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-firestore-ktx")
}

// Inicjalizacja
val db = FirebaseFirestore.getInstance()

Odczyt i zapis danych

Firestore zapewnia dwa tryby odczytu: jednorazowy (get) i w czasie rzeczywistym (addSnapshotListener). Odczyt jednorazowy pobiera dokument raz — przydatny dla ustawień i konfiguracji. Detektor subskrybuje zmiany — każda aktualizacja dokumentu automatycznie dostarcza zaktualizowane dane do wszystkich podłączonych klientów w czasie rzeczywistym. set() tworzy lub nadpisuje dokument, update() zmienia tylko określone pola bez nadpisywania całego dokumentu.

Według danych Google (2026), aplikacje średniej wielkości (100 tysięcy DAU) z Firestore w czasie rzeczywistym zużywają około 5-10 GB ruchu wychodzącego miesięcznie. Użycie pamięci podręcznej offline (Persistence Cache) zmniejsza ilość ponownych pobrań o 60-70%, ponieważ SDK pobiera tylko zmienione dokumenty po przywróceniu połączenia.

Tryb offline

Persistence Cache — wbudowany mechanizm Firestore do pracy bez internetu. SDK automatycznie buforuje wszystkie odczytane dokumenty na urządzeniu (do 500 MiB na Android). Po utracie połączenia odczyt kontynuowany jest z pamięci podręcznej, zapis jest kolejkowany. Po przywróceniu połączenia wszystkie odroczone operacje są wysyłane na serwer, a pamięć podręczna synchronizowana z serwerem. Do kontroli konfliktów używa się snapshot-metadata.hasPendingWrites i setOptions(ServerTimestampBehavior).

Reguły bezpieczeństwa i walidacja danych

Security Rules — to deklaratywny język rozgraniczenia dostępu do Firestore, wykonywany na serwerze Google przed każdą operacją odczytu lub zapisu. Rules nie wymagają kodu serwerowego — pisze się je w konsoli Firebase lub przez firebase CLI i wersjonuje przez Git. Każda operacja jest sprawdzana pod kątem zgodności z regułami, a w przypadku naruszenia zwracany jest błąd PERMISSION_DENIED.

Struktura reguł

Reguły Firestore Security Rules składają się z bloków match i wyrażeń allow. match określa ścieżkę do kolekcji lub dokumentu, allow określa dozwolone operacje (read, write, create, update, delete) i warunek — wyrażenie podobne do JavaScript zwracające wartość logiczną. Reguły mogą sprawdzać uwierzytelnienie (request.auth), dane żądania (request.resource.data), istniejące dane (resource.data), czas (request.time) i ścieżkę (request.path).

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }

    match /products/{productId} {
      allow read: if true;
      allow create: if request.auth.token.role == "admin";
      allow update: if resource.data.authorId == request.auth.uid;
    }
  }
}

Walidacja danych

Security Rules obsługują walidację typów i wartości po stronie serwera. Można zabronić zapisu, jeśli cena jest ujemna lub nazwa jest pusta. Wszystkie sprawdzenia są wykonywane na serwerze Google przed zapisem — gwarantuje to spójność danych niezależnie od klienta (Android, iOS, Web, Admin SDK). Rules nie chronią przed złośliwym Admin SDK — z definicji omija on reguły. Do pełnej ochrony używaj Transaction Functions i Firebase Extensions.