Firebase Realtime Database: vad det är, JSON-struktur och synkronisering

Vad är Firebase Realtime Database

Firebase Realtime Database är en av de första molnbaserade realtidsdatabaserna som lanserades av Google tillsammans med Firebase 2012. Det är en NoSQL-databas där data lagras som ett enda JSON-träd som är tillgängligt via en URL. Klient-SDK (Android, iOS, Web) prenumererar på specifika noder i trädet via WebSocket och får uppdateringar vid varje dataändring — utan att pinga servern och utan att implementera en egen Push-mekanism.

Historia och utveckling

Det ursprungliga Firebase grundades 2011 av James Tamplin och Andrew Lee, och den första produkten var just Realtime Database. Efter förvärvet av Google 2014 (enligt TechCrunch — för en summa mellan 50 och 100 miljoner dollar) integrerades databasen i Google Cloud och fick betydligt högre bandbredd. 2017 tillkännagav Google Firestore som en evolutionär ersättning, men Realtime Database fortsätter att aktivt stödjas och uppdateras. Enligt Google (2026) används Realtime Database fortfarande i över 1,5 miljoner aktiva projekt.

Gratis gränser och priser

Spark-planen (gratis) inkluderar: 1 GB lagring, 10 GB nedladdad data per månad, 100 samtidiga anslutningar och databasstöd i en region. På Blaze-planen (pay-as-you-go) betalar man för extra lagring (1 $/GB), trafik (0,12 $/GB) och samtidiga anslutningar (5 $ för varje 100 tusen över gränsen). För testning finns också emuleringsläge — firebase emulators:start — som kör Realtime Database lokalt utan anslutning till molnet.

Datastruktur: JSON-träd och normalisering

Realtime Database har inga tabeller, samlingar eller dokument — allt är ett enda JSON-träd som är tillgängligt på URL av typen https://project-name-default-rtdb.firebaseio.com/. Varje nyckel i trädet är antingen ett slutvärde (sträng, nummer, boolean, null) eller en nästlad nod med underordnade nycklar. Databasmotorn stöder inte JOIN, underfrågor eller aggregeringar — en fråga returnerar alltid innehållet i en enda nod med alla dess underordnade element.

Datormalisering

På grund av avsaknaden av JOIN i Realtime Database är datormalisering obligatorisk. Istället för ett nästlat träd (användare → lista över dess inlägg) delas data upp i platta listor med referenser via nycklar. Detta är standardmetoden: data denormaliseras så att läsning av en nod inte drar med sig hela kontexten. Till exempel lagras listan över chattmeddelanden separat från användarprofiler, och varje inlägg innehåller bara författarens ID, inte hela dess profil.

Frågor i Realtime Database

Frågor i Realtime Database utförs med filter (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt). Till skillnad från Firestore skapas index manuellt via avsnittet Rules (.indexOn). Om index inte har deklarerats returnerar en fråga med sortering felet PERMISSION_DENIED. Frågor fungerar bara på ett fält — sammansatta frågor (filter efter pris + sortering efter datum) stöds inte. För komplex filtrering dupliceras data ofta i olika noder med olika sorteringsnycklar.

Realtime Database vs Firestore: vad man ska välja

Valet mellan Realtime Database och Firestore är ett av de vanliga arkitekturbesluten när man startar ett projekt. Google rekommenderar Firestore för de flesta nya applikationer, men Realtime Database förblir det bästa valet för scenarier där minimal fördröjning av dataöverföring är kritisk.

Tre nyckelscenarier för Realtime Database

Första scenariot — flerspelarspel med tillståndssynkronisering (schack, kortspel, realtidsaction). Fördröjningen för Realtime Database är 10-30 ms jämfört med 50-100 ms för Firestore i samma region. Andra scenariot — chattar och meddelandetjänster med hög meddelandefrekvens. Realtime Database prissätts efter datavolym, inte efter antal skrivningar, vilket gör den betydligt billigare än Firestore vid frekvenser över 1 meddelande per sekund. Tredje scenariot — närvaro (presence) för användare online/offline, där onDisconnect-hanterare i Realtime Database gör det möjligt att atomiskt ställa in status vid anslutningsavbrott.

Enligt Google (2026) väljer cirka 15 % av nya Firebase-projekt medvetet Realtime Database — när teamet tydligt förstår kraven på fördröjning, datastruktur och budget. I de återstående 85 % av fallen är Firestore det säkrare valet tack vare bättre skalbarhet, kraftfullare frågor och automatisk replikering.

Integration av Realtime Database i Android

Anslutning av Realtime Database till en Android-app görs genom att lägga till beroendet firebase-database-ktx i build.gradle. FirebaseDatabase-objektet är tillgängligt via getInstance(url) — flera databaser kan anslutas inom ett enda Firebase-projekt. Efter initiering upprättar SDK automatiskt en WebSocket-anslutning till servern och börjar synkronisera data.

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

// Initiering med anpassad URL
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Skriva och läsa data

Realtime Database använder DatabaseReference-objektet för alla operationer. setValue() skriver data till den angivna noden och ersätter hela dess innehåll. push() genererar automatiskt en unik nyckel (baserad på en tidsstämpel) för att lägga till ett element i en lista — detta är standardsättet att skapa chattmeddelanden, inlägg och poster. updateChildren() ändrar flera noder atomärt i en enda operation. addValueEventListener prenumererar på ändringar av en nod och får en callback vid varje datauppdatering.

data class Message(
    val author: String = "",
    val text: String = "",
    val timestamp: Long = ServerValue.TIMESTAMP
)

class ChatRepository(private val ref: DatabaseReference) {
    fun sendMessage(author: String, text: String) {
        val msg = Message(author = author, text = text)
        ref.child("messages").push().setValue(msg)
    }

    fun observeMessages(): Flow<List<Message>> = callbackFlow {
        val listener = ref.child("messages")
            .addValueEventListener(object : ValueEventListener {
                override fun onDataChange(snapshot: DataSnapshot) {
                    val messages = snapshot.children.mapNotNull { it.getValue(Message::class.java) }
                    trySend(messages)
                }
                override fun onCancelled(error: DatabaseError) {}
            })
        awaitClose { ref.removeEventListener(listener) }
    }
}

Realtidssynkronisering och offline-läge

Synkroniseringsmekanismen för Realtime Database är baserad på WebSocket-protokollet (tidigare — long-polling). Klienten skickar en begäran om att prenumerera på en specifik nod och servern håller anslutningen öppen. Vid varje dataändring i den prenumererade noden skickar servern fullständig JSON för den noden till klienten. SDK på klientsidan uppdaterar automatiskt det lokala tillståndet och anropar motsvarande callbacks (onDataChange).

OnDisconnect — frånkopplingstriggers

OnDisconnect — en unik funktion i Realtime Database som saknas i Firestore. Utvecklaren kan registrera en skrivoperation som automatiskt utförs på servern när klientanslutningen bryts. Detta används för närvarostatus: "user123/status": "online" med onDisconnect.setValue("offline"). Om användaren stänger appen eller förlorar internet, kommer servern automatiskt att ställa in status "offline" inom högst 3 minuter (konfigurerbart i Firebase-konsolen).

Offline-cache

Persistence i Realtime Database aktiveras med en rad: FirebaseDatabase.getInstance().setPersistenceEnabled(true). SDK cachar den senaste statusen för alla prenumererade noder på disk (som standard upp till 10 MiB, konfigurerbart upp till 100 MiB). Vid anslutningsförlust fortsätter klienten att arbeta med cachad data och alla skrivoperationer placeras i kö. När anslutningen återställs skickar SDK alla ackumulerade ändringar till servern i rätt ordning (FIFO).

Enligt Google (2026) förlorar appar med aktiverad persistence-cache 40% mindre ofta användardata vid anslutningsavbrott. Men om klienten har samlat på sig mer än 1000 uppskjutna operationer kan servern avvisa alla och begära fullständig synkronisering — detta är en skyddsmekanism mot föråldrade klienter.

Säkerhetsregler och validering

Security Rules i Realtime Database är en JSON-konfiguration som beskriver vem och under vilka förutsättningar som kan läsa och skriva data i varje nod. Reglerna fungerar på Googles server och utförs före varje operation. Som standard (i produktion) rekommenderas att ställa in reglerna i "stängt" läge — endast autentiserade användare har åtkomst.

Struktur för rules

Reglerna för Realtime Database skrivs i JSON-format med avsnitten .read, .write, .validate, .indexOn. Till skillnad från Firestore (som använder match-syntax) använder Realtime Database nästlade objekt som speglar datastrukturen. Villkor kontrollerar auth (autentisering), data (befintlig data), newData (ny data vid skrivning) och now (servertid). Valideringsregler (.validate) gör det möjligt att kontrollera typer, värdeintervall och datastruktur.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid",
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      ".indexOn": ["timestamp"],
      "$msgId": {
        ".read": true,
        ".write": "auth.uid !== null",
        ".validate": "newData.child('text').isString() && newData.child('text').val().length <= 500"
      }
    }
  }
}

Kaskadbeteende och testning av rules

Reglerna för Realtime Database ärvs kaskadartat — om .read = false på den högsta nivån är alla underordnade noder otillgängliga för läsning oavsett deras egna regler. Firebase tillhandahåller en regelsimulator i konsolen där operationer kan testas med olika auth-tokens före driftsättning. Det rekommenderas att alltid testa regler i simulatorn — ett fel i en regel kan öppna åtkomst till privata data för alla användare. Enligt Google (2026) orsakas 40% av dataläckor i Firebase-projekt av felaktigt konfigurerade säkerhetsregler.