Firebase Firestore — vad är det, dokument och NoSQL-samlingar

Vad är Firebase Firestore

Firebase Firestore är en molnbaserad NoSQL-databas som lanserades av Google 2019 som efterträdare till Realtime Database. Firestore är byggd på infrastrukturen hos Google Cloud Spanner och Google Cloud Datastore, vilket ger strikt datakonsistens inom en enda transaktion och automatisk multi-regional replikering. SDK stöder Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform och Unity.

Utveckling från Realtime Database

Firestore tillkännagavs på Google I/O 2017 som “Cloud Firestore” — en lösning som eliminerar de viktigaste begränsningarna hos Realtime Database: brist på stöd för komplexa frågor, omöjlighet att skala data över flera noder och svag konsistens. Enligt uppgifter från Google (2026) bearbetar Firestore över 1 biljon frågor per dag och är standarddatabasen för 80% av nya Firebase-projekt. Realtime Database förblir dock relevant för scenarier med ultra-låg latens (spel, samarbetsredigering) tack vare sin enkla JSON-struktur.

Firestores gratisgränser

Firestore erbjuds enligt en pay-as-you-go-modell med generösa gratisgränser på Spark-planen: 1 GB lagring, 10 GB nätverkstrafik per månad, 50 tusen läsoperationer, 20 tusen skrivoperationer och 20 tusen borttagningsoperationer per dag. På Blaze-planen är allt lika gratis, och överskridanden debiteras: $0.06 per 100 tusen läsoperationer, $0.18 per 100 tusen skrivoperationer. Enligt uppgifter från Google (2026) överskrider 90% av projekten inte gratisgränsen.

Datamodell: samlingar, dokument och fält

Firestores datamodell är hierarkiskt organiserad: roten innehåller samlingar, varje samling innehåller dokument, varje dokument innehåller fält (primitiva typer, arrayer, Map) och nästlade samlingar (subcollections). Djupet på nästling av samlingar är inte begränsat, men ett dokument kan inte direkt innehålla ett annat dokument — endast via en referens (Reference type).

Samlingar och dokument

En samling är en behållare för dokument med automatiskt genererade eller angivna identifierare. Varje dokument är ett JSON-liknande objekt med en storlek på upp till 1 MiB. Dokumentfält kan vara strängar, tal, booleska värden, arrayer, Map, tidsstämplar (Timestamp), geografiska punkter (GeoPoint) och referenser till andra dokument (Reference). Dokumentstorleken är begränsad till 1 MiB, inklusive namnen på alla fält.

Batch-skrivning och transaktioner

Firestore stöder atomära transaktioner på databasnivå. En transaktion kan läsa och skriva flera dokument — Commit tillämpar alla ändringar atomärt eller inga. Maximalt 500 operationer per transaktion, tidsgräns 60 sekunder. Batch-skrivning (batch write) är en icke-transaktionell atomär skrivoperation utan läsfas. Transaktioner är kritiska för finansiella operationer, platsbokningar och inventering.

Jämförelse av Firestore och Realtime Database

Valet mellan Firestore och Realtime Database beror på projektets krav. Båda databaserna ingår i Firebase-ekosystemet, tillhandahåller synkronisering i realtid och är tillgängliga på alla plattformar, men skiljer sig fundamentalt i datamodell, skalning och prissättning.

Viktiga skillnader

Realtime Database lagrar data i ett enda JSON-träd, vilket är bekvämt för enkla strukturer men försvårar skalning vid nästling djupare än 3 nivåer. Firestore använder en samlings-dokumentmodell med automatisk sharding, vilket möjliggör skalning upp till miljontals dokument utan prestandaförsämring. Enligt uppgifter från Google (2026) stöder Firestore upp till 10 tusen samtidiga anslutningar till en enda samling utan hastighetsförlust, Realtime Database — upp till 200 tusen anslutningar till en enda instans.

Prissättning

Realtime Database debiteras baserat på volymen överförda data (nedladdade byte) och antalet samtidiga anslutningar. Firestore — baserat på antalet operationer (läsning, skrivning, borttagning). För applikationer med frekventa små uppdateringar (chatt, notifieringar) är Firestore vanligtvis mer fördelaktigt — varje skrivoperation har ett fast pris oavsett datastorlek. För applikationer med sällsynt läsning av stora datamängder kan Realtime Database vara billigare.

Googles rekommendation (2026): använd Firestore som standarddatabas för nya projekt och Realtime Database — för spel och applikationer där minimal latens (mindre än 50 ms) är kritisk och datastrukturen är platt. Båda databaserna kan fungera samtidigt i ett projekt.

Frågor, index och paginering i Firestore

Firestore-frågor utförs på samlingar eller grupper av samlingar med filtrering, sortering och begränsning. Till skillnad från Realtime Database, där varje fråga är en genomgång av hela JSON-trädet med filter på klientsidan, utför Firestore alla frågor på servern med hjälp av förskapade index. Detta garanterar att frågans komplexitet endast beror på resultatets storlek, inte på samlingens storlek.

Frågetyper

Firestore stöder filtrering på ett eller flera fält (equality, range, in, array-contains, array-contains-any), sortering stigande och fallande, begränsning och markörer för paginering. Begränsningar: sammansatta frågor med filtrering på olika fält (where price > 10 AND where category == “books”) kräver ett sammansatt index; OR-frågor är förbjudna (istället används in och array-contains-any) och frågor med olikhet på olika fält är förbjudna.

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)
}

Automatiska och sammansatta index

Firestore skapar automatiskt index för enskilda fält — frågor på ett enskilt fält fungerar utan någon konfiguration. För frågor med två eller fler fält (filtrering + sortering) skapas sammansatta index. Vid första sändningen av en fråga returnerar Firestore ett fel med en länk till konsolen, där indexet kan skapas med ett klick. Maximalt 200 sammansatta index per databas. Index kan exporteras och importeras via firebase CLI.

Integration av Firestore i Android

Anslutning av Firestore till en Android-applikation görs standard via Firebase BOM. Efter att ha lagt till beroendet firebase-firestore-ktx är FirebaseFirestore-objektet tillgängligt via getInstance() — utan extra nycklar eller token. Firestore använder samma Firebase-projekt som de andra tjänsterna.

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

// Initiering
val db = FirebaseFirestore.getInstance()

Läsa och skriva data

Firestore erbjuder två läslägen: en gång (get) och i realtid (addSnapshotListener). Engångsläsning hämtar dokumentet en gång — användbart för inställningar och konfiguration. Lyssningsfunktionen prenumererar på ändringar — varje uppdatering av ett dokument levererar automatiskt uppdaterad data till alla anslutna klienter i realtid. set() skapar eller skriver över ett dokument, update() ändrar endast de angivna fälten utan att skriva över hela dokumentet.

Enligt uppgifter från Google (2026) förbrukar medelstora applikationer (100 tusen DAU) med Firestore i realtid cirka 5-10 GB utgående trafik per månad. Användning av offline-cache (Persistence Cache) minskar mängden upprepade nedladdningar med 60-70%, eftersom SDK endast laddar ner ändrade dokument när anslutningen återställs.

Offline-läge

Persistence Cache är en inbyggd mekanism i Firestore för att arbeta utan internet. SDK cachar automatiskt alla lästa dokument på enheten (upp till 500 MiB på Android). Vid förlust av anslutning fortsätter läsning från cachen, skrivning köas. När anslutningen återställs skickas alla uppskjutna operationer till servern och cachen synkroniseras med servern. För konflikthantering används snapshot-metadata.hasPendingWrites och setOptions(ServerTimestampBehavior).

Säkerhetsregler och datavalidering

Security Rules är ett deklarativt språk för begränsning av åtkomst till Firestore, som körs på Googles server före varje läs- eller skrivoperation. Rules kräver ingen serverkod — de skrivs i Firebase-konsolen eller via firebase CLI och versionshanteras via Git. Varje operation kontrolleras för överensstämmelse med reglerna, och vid överträdelse returneras ett PERMISSION_DENIED-fel.

Reglernas struktur

Reglerna för Firestore Security Rules består av match-block och allow-uttryck. match definierar sökvägen till samlingen eller dokumentet, allow specificerar de tillåtna operationerna (read, write, create, update, delete) och villkoret — ett JavaScript-liknande uttryck som returnerar ett booleskt värde. Reglerna kan kontrollera autentisering (request.auth), förfrågans data (request.resource.data), befintlig data (resource.data), tid (request.time) och sökväg (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;
    }
  }
}

Datavalidering

Security Rules stöder validering av typer och värden på serversidan. Skrivning kan förbjudas om priset är negativt eller namnet är tomt. Alla kontroller utförs på Googles server före skrivning — detta garanterar datakonsistens oavsett klient (Android, iOS, Web, Admin SDK). Rules skyddar inte mot skadlig Admin SDK — den kringgår per definition reglerna. För fullständigt skydd, använd Transaction Functions och Firebase Extensions.